I just has a system fall over mid way through a glibc upgrade because it ran out of space in /lib half way through qmerging. To prevent things like this, could ebuild make a temporary backup of any files it overwrites during an upgrade during the qmerge phase? Then if the qmerge failed to complete, ebuild could roll back by replacing the old files and removing any new files - then you could be assured that packages are always in a consistent state when ebuild/emerge exits. Reproducible: Always Steps to Reproduce: 1.Fill up the disk so there is less than sufficiet space to qmerge an upgraded package (but so that there is sufficied space to build the package without merging) 2.emerge a package Actual Results: ebuild qmerge will exit mid install, complaining of disk space. Package is left in inconsistent state. If package is vital (eg glibc) the system may become unstable. Expected Results: ebuild backs out the incomplete qmerge and restores the old verion of the file.
*** This bug has been marked as a duplicate of 88997 ***
In my case with glibc that wouldn't have saved me (though I will keep it in mind for future). Once emerge had exited with glibc partially upgraded, I tried rerunning after clearing some disk space for it, but at this point emerge would segfault. That's why I'm asking that emerge leaves packages either entirely installed or entirely not installed, because if it exits part way through, then it may leave the system in a state that prevents you from rerunning emerge to correct the problem.
This is a little bit different and more important in my opinion.
Comment #2: If you have a binary glibc package, you could hopefully get a working system with tar xpjf gcc-*.tbz2 -C / (at least unless tar segfaults as well ;-) If you don
Comment #2: If you have a binary glibc package, you could hopefully get a working system with tar xpjf gcc-*.tbz2 -C / (at least unless tar segfaults as well ;-) If you don´t have one, have a look at http://dev.gentoo.org/~avenj/bins/ and pick up one.
Eh, sorry - I obviously meant tar xpjf glibc-*.tbz2 -C /
Thanks for the suggestions, however ssh segfaulted before I could fix it and the system wouldn't boot after that. So I had to boot into a Knoppix CD and copy the files into place and reboot.
So, Jason/Chris, are you saying that in this instance having done the merge with --buildoldpkg as proposed in bug 88997 would not have allowed you to fix this issue? I'm just trying to clarify. I agree that it would be great to have a way to back out of a merge, but I think it would be a lot better if it was an option to emerge, rather than always on. Jakub, can you do the emerge from .tbz2 from a livecd boot? Of course, the number of packages that will render the system non-booting after emerge failure (I hope) is pretty low, so that's a pretty special case. Also, I question whether the requested behavior would fix the problem. It seems to me that it would just increase the amount of diskspace you would have to have. Say, for instance, you had enough space to make your backup copy of all the old files, but not enough to then merge in the new ones. Seems to me that the merge would still die halfway through, and that you'd be back in the same spot you were (machine non-booting). Now, you'd have the old files there, so when you went back in on the livecd you could just copy them over.....but you'd have to free up the space first anyway, and assuming you can emerge from .tbz2 while in a livecd, that would need less space and be an easier procedure. It would also be much more useful for other things, as it would allow the admin to back out of any package upgrade at any time, quickly and painlessly. For the merges that don't bring the machine down, but do stop working right, --buildoldpkg would be much handier than this. I'm certainly interested in what you think the downsides of that approach would be.
In my case, emerge did not segfault in the first instance - it identified a full disk mid way through merging glibc and bailed. After that, emerge and many other things would not rerun because of broken glibc. So --buildoldpkg may not have helped me because tar or bzip may have segfaulted due to broken glibc too. As for diskspace, think about it, in order to backup a file, you have to do it before you merge over the top of it. So even if you were only backing up files as you were going along and then ran out of space mid way through, and so only had some of the files backed up - those are the only files you need to restore, so emerge could restore the system to a safe state before bailing. I agree that --buildoldpkg is a good idea, but in this case it still results in a system that needs rescuing with a boot floppy. Backing up during a merge phase and restoring on failure would eliminate that need.
I still vote to enhance portage & emerge to support roll-back / roll-on feature. Just right now emerge -uD brought me a crappy python in. Now I will have to run and fix it...
Thomas, for portage making backups, see bug 54113. This is more for portage encountering a fatal error while running and not recovering properly, leaving the system in a dead state more than portage making backups of your stuff and restoring them for you.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening for duping
*** This bug has been marked as a duplicate of bug 23851 ***
