Red Hat Bugzilla – Bug 650854
Preupgrade installation process halted due to a package problem
Last modified: 2013-02-13 19:49:02 EST
Description of problem: A Fedora 13 64bit system attempted to be migrated to Fedora 14 by using the preupgrade method. Preupgrade downloaded all packages, rebooted the system and when it reached the installation of the packages the VirtualBox package produced an error and the only option was to exit the installer. The current system was left in an inconsistent state.
Version-Release number of selected component (if applicable):
How reproducible: Use preupgrade for upgrading to Fedora 14
Steps to Reproduce:
1. Run preupgrade
2. Reboot when ready
3. After automatic reboot watch the package installation progress
Actual results: An exception in installation is produced and the installer exits
Expected results: The installer should have continued to install the rest packages and skip the defected one.
Additional info: Please, advise which logs do you need to be provided. I'd also be very grateful if you could also provide steps to recover my system. A rescue DVD media can be used to check the impact of failed installation. Can the rpm transaction be recovered?
I'll reassign to anaconda, although I'm not sure. Help welcomed.
Is this the error message you saw:
self.messageWindow(_("Error Installing Package"),
_("A fatal error occurred when installing the %s "
"package. This could indicate errors when reading "
"the installation media. Installation cannot "
"continue.") % name,
Or was it something like this:
intf.detailedMessageWindow(_("Error Running Transaction"),
Without knowing the exact error message, it's hard to speculate on what could be the problem.
The former! And in the "%s" string the package "VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm" was printed.
I've good news. I was able to boot the installation using the old fedora 13 kernel. Fedora 14 and "Upgrade to Fedora 14" kernels are not working as expected. So, there is no need to use a rescue DVD. I can retrieve the required logs from the system itself if you want.
Additional information that might be helpful. I don't think the package itself in general is the problem, as I have upgraded other installations having VirtualBox without problems. The only thing I remember in that specific installation, is that I got a "Filesystem /var is full" error message on my first attempt. I've cleaned up the filesystem and tried again. However, I think that I've selected to repeat the installation and not to continue. That info might be false, since I'm not sure about that. So, it might be the case the package was downloaded insufficiently due to "filesytem full" error and used again for upgrading the second time!?!? Anyway, don't take what I've said for granted; I don't want to mislead your investigation.
That error message occurs when there is an error unpacking the package, which is a pretty serious condition. During installation, there's /tmp/anaconda.log and /tmp/syslog which would be very handy to see. They are only copied to the finished system on success, so you're going to have to reproduce the condition in order to get the logs off it.
Created attachment 459195 [details]
Log file /root/upgrade.log
Created attachment 459196 [details]
Log file /root/upgrade.log.syslog
Only the following files were found that concern the upgrade:
I don't know if I'm able to repeat the installation, as it is already reporting that is Fedora 14. What should I do to remove the inconsistencies and finish the upgrade. Can yum help me on this stage or should I use the installation DVD to finish the upgrade? Is anything else that is need like cleaning the pending rpm transaction?
*** Bug 651623 has been marked as a duplicate of this bug. ***
Well this is the problem, though I do not yet know why it's happening:
error: unpacking of archive failed on file /usr/lib/virtualbox/VBoxEFI32.fd;4cd5a0f2: cpio: read failed - Resource temporarily unavailable
Thank you very much for your reply. I think the problem is related to the corrupted virtualbox package downloaded by preupgrade. If I try to extract the rpm file, I'm getting an error:
$ rpm2cpio /var/cache/yum/preupgrade-virtualbox/packages/VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm | cpio -idmv
cpio: premature end of file
Indeed, the file is only 1.6MB long:
-rw-r--r-- 2 root root 1.6M Nov 6 19:06 /var/cache/yum/preupgrade-virtualbox/packages/VirtualBox-3.2-3.2.10_66523_fedora14-1.x86_64.rpm
where the actual rpm package from Oracle's repository is 42MB:
That might caused by the /var filesystem full error that I got earlier and although I've instructed preugrade not to continue the previous downloading, for the packages it seems it kept the faulty one. If you add Bug 651278, it looks like preupgrade needs a lot of revising in the package downloading phase. It also yields questions of how it passed the transaction test successfully in the first place. It must be ensured that all required packages have been downloaded successfully, before continuing to any system upgrade.
Let's reassign to preupgrade for now, given that it probably should have caught this download failure.
OK, forget my /var filesystem full feedback. It is irrelevant. There are users that faced the same problem without having such issues.
My latest experience from VirtualBox repository with a "yum update" recently is that for some reason it might drop your connection and yum reports a "no mirrors to try" error and exits.
Apparently, it seems that preupgrade does not stop and continue on the next package, leaving the VB package download incomplete with a disastrous results for our system upgrade process. The problem might be reproduce with a repository on a remote host that will drop the connection and there will be no other mirrors. VirtualBox repo is using baseurl anyway:
$ cat /etc/yum.repos.d/virtualbox.repo
name=Fedora $releasever - $basearch - VirtualBox
This is really irritating. Not only I had my desktop ruined by the upgrade procedure of F13 to F14 as described in the present bug report, but also now my laptop when attempted yesterday to upgrade from F14 to F15.
Upgrade was halted again in the VirtualBox package and the installer exited leaving my system half upgraded. If you are not able to perform a simple validation of the downloaded package integrity, please at least add a warning message to de-activate third party repositories. Bugs that concern that major system failures shouldn't be neglected, as they cause a great frustration.
Please, advise if I should open a new a new bug report for F15 version or to move the existing report to F15. I'd also appreciate a formal procedure of how to recover my system. Format is not an option. If I remember well yum-complete-transaction couldn't help me to complete the upgrade transaction the first time and I had to resolve the duplicated packages manually.
Luckly, this time I saved myself from that bug removing VirtualBox package.
I was sure that would happen again, and indeed...
This bug and the old ntfs-resize bug created a lot of damage everywhere.
I've tried the solution to repeat the installation. Booted with a rescue disc and with the help of a USB stick I've overwritten /var/cache/yum/preupgrade/VirtualBox-4.0-4.0.8_71778_fedora15-1.x86_64.rpm with a correct copy and rebooted the kernel "Upgrade to F15". It continued on upgrading the rest 240 packages left and Virtualbox now succeeded, but installation progress hung at the post configuration, because yum crashed due to duplicate packages and there was an error message yum is in use by other app, without though any yum running. I removed /var/run/yum.pid and it rebooted.
The f15 kernel produces kernel panic as it cannot find root filesystem, because the initramfs is missing from the grub.conf. In fact it wasn't produced at all. It is missing from /boot directory. The f14 kernels stuck at plymouth fedora logo. I've booted again in rescue mode and this is the wonderful command that seems to work to get rid of all duplicate f14 packages:
It removed 966 packages of f14. There still some issues that "yum check" and "yum list extras" reports, but I hope to resolve them manually. Kernel issue resolved with "yum reinstall kernel".
Although I've managed to get my system back, I would really appreciated a proper way to handle this kind of issue.
Yesterday I updated to Fedora 16 without remembering about this problem, and I did not have problems
You were very luck then, as the issue is caused by insufficient download of the virtualbox package. It is not always reproduced. I remember having upgraded 2 desktops and 1 laptop having the same virtualbox configuration and the problem only occurred on the 1 desktop. It's like 33% probability for the issue to occur.
Unless preupgrade download procedure is improved to ensure the integrity of the downloaded packages, I would suggest to disable Virtualbox repository before proceeding in a system upgrade. You can enable it afterwards where the package download issues will not harm your system. For F16 upgrade by using preupgrade, I am going to disable Virtualbox repository for sure. Repository disabling should be enough. No need to uninstall the package.
I wonder why this issue is not logged to http://fedoraproject.org/wiki/Common_F16_bugs. It is a major issue for an upgrade procedure to leave your system broken, half upgraded with duplicate packages.
It is a wiki, maybe you can edit it and add this informations
"Or, add the CommonBugs keyword to the bug report. Someone from the QA team will then inspect the issue to determine whether the bug should be listed as a common bug."
Let's wait for an official answer if that should be logged as common bug.
Fedora Bugzappers volunteer triage team
Thanks Adam for the Common F16 bug! I couldn't have written it better.
Hey guys, I need some help in rescuing my system. And this bug seems as a good place to put some hints, since people look here.
I had the same problem - my preupgrade from F15 to F16 failed miserably. And now I have no clue how to make the system working again.
I had not only virtualbox repo, but also google-chrome repo and adobe repo. All directories associated with those repositories in /var/cache/yum/preupgrade-*/packages/ are empty! It is not that I have partially downloaded rpms - I have none.
For eg. /var/cache/yum/preupgrade-virtualbox/packages/ is empty, so I do not even know which rmps are missing.
None other kernels left on my system will boot, nor "Update to F16" option will boot. Is there any way to fix preuprade process from the command line in the rescue mode? Or the only option is to format everything?
Do you happen to have /var as a separate filesystem? I think you have been hit by another F16 common Bug 748119. That could explain why your downloaded packages are not there. Maybe /var is not mounted.
If you had any network problems during package download, maybe Bug 651278 is also for you. In any case, I would suggest to use DVD upgrade method that should work to at least get your system back and then to resolve any inconsistencies.
OK, I found the solution. I have been working whole night and finally managed to rescue the system. The biggest problem was: Rescue CD!
Everyone in the manuals/helps etc. writes: "Just run: linux rescure on boot and blah blah..." from a RescueCD or from Install DVD! This is bad. Probably 50% of people has no DVD reader in their laptops now! Fedora do not offer Rescue CD as a download option any more. And the Install DVD is so big, that it takes many many hours to download. More over, this full install DVD does not fit my USB drive.
So this is a mess! Please fix the tutorials to be more specific and modern!
(Can you feel I am little bit angry? I have just spent whole night on fighting a thing that should be easy and seamless, and with no reasonable help from manuals on the Fedora web pages.)
So the solution:
1. I have found out, with trial and errors, that "Network Install CD" (not only "Install DVD") has "linux rescue" mode embedded. Fedora-16-i386-netinst.iso is much smaller and can be downloaded faster. You will need only 512 MB thumb drive, not a 4.0 GB one!
2. Then you need to use some other working machine to set up iso image on the USB drive. But! You need really new machine - for some reason, when I did this on CentOS 5.7 using their livecd-tools, nothing worked.
Fortunately I had a Fedora 15 Live USB stick leftover from the previous installation. (Live image is way smaller than Install DVD, about 800 MB, but you still need second USB stick, but about 1GB big. Although I have no idea how I would put this Live CD image in if I hadn't have it already set up, because of incompatibilities of the livecd-tools between older and newer distributions. Maybe by some iterative process...?)
3. So I boot my dead machine from this LiveCD stick, and than I attach second stick, the one 512 mb for the netinst. I use command "df" in the terminal (or look into /var/log/messages) to see on which /dev/sd* it was attached. Lets say it was /dev/sdc1
Than in the terminal I put this:
#> su -
#> yum install livecd-tools
#> umount /dev/sdc1
#> livecd-iso-to-disk pathto/Fedora-16-i386-netinst.iso /dev/sdc1
Done. Now my stick is a Rescue CD
4. Reboot from to the new USD drive. Put a command "linux rescue" when you will see a command prompt.
5. Answer to the questions. The most important thing is to setup an internet connection. I was lucky, since I had and ethernet cable and a router handy (although in newer rescue images it is possible that Wifi will work as well)
6. After you got a Shell command line to write commands to. Write: chroot /mnt/sysimage/
7. Now edit all /etc/yum.repos.d/*.repo that are third party and you think might cause a problem, and put enable=0 instead of enable=1. I used "vi" to edit in text environment (push 'i' to start editing, push "Esc" and then write ":wq" to save and quit).
I had skype, adobe, virtualbox, google-chrome and google-talkplugin repos. VirtualBox is the most suspect one, but when I looked into /var/cache/yum/preupgrade-skype/packages/ directory this was empty as well, same with preupgrade-virtualbox, etc. So to be on the safe side, I disabled all third party repos. I left all fedora repos and rpmfusion repos as they were.
8. I have found out that command "preupgrade" does not work in the text mode. But, there is another command called "preupgrade-cli" and apparently this works. So start this one.
9. When this finishes, write "exit" to reboot you machine. Then boot into "Upgrade to Fedora 16" menu option. This will take a while to finish, but you should see graphical feedback, more than just a cursor in the corner.
10. At the end of the process I had an error saying: "There was an error installing the bootloader. The system may not be bootable." Very informative and reassuring stuff.
However I was able to choose different menu option in the boot by pushing "Arrow down" repeatedly, from the power on up to the moment a menu showed up. First and default boot menu option was still "Upgrade to Fedora 16", but I have chosen the newest kernel to boot. And voila! Fedora 16 started!
11. I re-enabled all repositories that previously been disabled by me (virtualbox, google-talkplugin, google-chrome, google, skype, adobe-linux-i386). And issued:
"yum clean all" and "yum update".
Interestingly non(!) of the packages from these repositories have been updated(!?). This would make the fact, that all /var/cache/yum/preupgrade-virtualbox/packages/ and alike were empty, understandable . But it would leave a mystery what actually went wrong in the first preupgrade.
12. Very useful program is "package-cleanup". "-h" option will say whats available. "--dupes" will show that you still have leftovers from older Fedora. "--cleandupes" will clean them.
I did it, and interestingly it tried to remove much more than required! Totaling 2.8 GB and lots of packages from Fedora 16, which I would argue are important, like:
- libdvbpsi both fc16 and fc15
- autocorr-en fc16 version along with fc15
- hunspell-en fc16 version along with fc15
- libreoffcie-langpack-en fc16 and fc15
and for depedencies:
- PyQt fc16
- vlc f16
- phonon fc16
- smolt fc16
- and whole Libre Office fc16
(!!!) this is certainly weird and wrong.
The reason for this might be that some packages have the same version numbers in fc15 and fc16, and cleandupes is cleaning both versions. This requires to remove more fc16 packages due to dependencies. For example:
There is also some problem with hunspell or hunspell-en, which I do not understand, but it also want to be removed, although the versions are different.
So I have removed all problematic packages by hand:
libdvbpsi - both versions
hypen - fc15 version
hypen-en - fc15 version
hunspell - fc15 version
hunspell-en - fc15 version
This removed some of the fc16 packages, but fortunately not the big LibreOffice.
After this the 'package-cleanup --cleandupes' wanted to remove only fc15 packages. So I did it.
13. Now, when the package 'fedora-release' for fc15 was removed from the system, as a duplicate of 'fedora-release' for fc16, one can start to reinstall erroneously removed packages.
14. Also the problem with bootloader can be solved now.
You can see into /boot/grub/grub.conf that entries for old kernels and Update are still in place. The reason is that their transitioned from grub to grub2 between fc15 and fc16. So installer (anaconda) didn't change grub settings, only created grub2 settings. And grub2 is too big to fit before my /boot partition on the disk! That is why the bootloader installation (grub2) didn't succeed.
But WHY(!) preupgrade didn't informed me that I have to change partitions before doing the preupgrade???!!!!!
fdisk -l /dev/sda shows my boot partition stating on sector 63. So there is 32kb of free space before. This is too small for grub2.
I really wanted to install old grub and just modify configuration by myself to accommodate new kernel, but this is not easy since grub2 obsoletes grub, thus yum does not allow you to install old version, nor the yum localinstall nor rpm. This would be the easiest option, since I know that I have enough space for old grub. I booted from kernel 126.96.36.199-1.fc15.i686 using old grub that was installed already. It is nice at least that anaconda (installer) didn't messed this up one. But I would like to put configuration for the new kernel, i.e, 3.1.9-1.fc16.i686 into boot loader.
This requires to shrink and move first partition, so it starts on for example on sector 2049 (to give it 1 MB of free space before). I used gparted to do this. But first I had to boot the machine from the Live USB once more. Then:
> su -
> yum install gparted
and then in side the gui right click on the first partition and do move/resize to put 1 MB free in front of. After this is finished, do reboot into 'linux rescue' once more using the other USB drive. This is important as you need to install new bootloader in to the beginning of the disk.
To install new configuration to the boot record do:
> chroot /mnt/sysimage
> grub2-install /dev/sda
or whatever you primary disk is called.
Reboot and new grub should welcome you.
15. Command 'package-cleanup --oldkernels' will remove old kernels. You can see what kernel you are running now by:
You can see what kernels you have installed on the system with:
yum list kernel
16. I have experience one bug more:
My login screen would not start, nor the X server, on any kernel I was trying. In the /var/log/messages I have found the line saying:
gnome-session ERROR unable to open /etc/dconf/db/gdm specified in dconf profile
I spend an hour chasing this. It seams that installer didn't do required step, which is completely new to Fedora 16 and its new 'dconf' system. Every time the dconf configurations files are changed, one should run:
> dconf update
And that is it!
After circa 16 hours of research and work I was able to make my newly preupgrated Fedora to run. The reason for this was bunch of bugs in the process:
1. preupgrade not informing me to disable third party repositories
2. preupgrade hanging on third party repositories even there was nothing to update
3. preupgrade not informing me that I have to little space for the newer "better" bootloader
4. instalator not issuing command: dconf update
5. yum repositories having bugs in the dependencies, or package-cleanup having bug in understanding versions, so the cleandupes process would uninstall lots of packages from the new system
6. manuals not saying where I can find linux rescue image. All say about Install DVD, but it is too big to fit on many USB drives, and too big to download just to fix an issue.
7. and all minor things alike...
I know I should write 10 bug reports on bugzilla now, but I am too tired and too pissed of. I hope that someone will google this post, and it will help him.
Next time this will happen to me, I will install Ubuntu. I would spend much less time by just installing new system from scratch.
(In reply to comment #24)
> dconf configurations files are changed, one should run:
> > dconf update
> And that is it!
Thanks, I had the same problem with prefdm failing to start gdm because /etc/dconf/db/gdm is actually now /etc/dconf/db/gdm.d . Running "dconf update" fixed the problem for me, so your Bugzilla comment was helpful to me (yes, I found it via Google, and yes, it saved me a lot of time... Much appreciated).
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Long live preupgrade! Let's hope that fedup is not affected by the same issue. The ticket can be closed.
Panos: sadly, busted packages in third party repositories are beyond our control :( Perhaps we should add something to the Fedup instructions which suggests disabling third party repos before doing fedup, though.
Yes, that's fair enough.
I'm also wondering why the existing RPM transaction test cannot catch corrupted packages. There might be already a way of package verification of the downloaded packages. I think it is a very important requirement and other PMS already doing that. Our supreme and beloved yum shouldn't be an exception :)
Fedup produces the following related error message when finished:
(488/490): libcdaudio-0.99.12p2-16.fc18.x86_64.rpm | 40 kB 00:00
(489/490): libtiff-4.0.3-2.fc18.i686.rpm | 170 kB 00:01
Downloading failed: Errors were encountered while downloading packages.
VirtualBox-4.2-4.2.6_82870_fedora18-1.x86_64: [Errno 256] No more mirrors to try.
Repeating fedup for downloading it again.
Second attempt was better:
root@charon: ~ # fedup --network 18
setting up repos...
getting boot images...
.treeinfo | 1.1 kB 00:00
setting up update...
finding updates 100% [=========================================================]
verify local files 100% [======================================================]
VirtualBox-4.2-4.2.6_82870_fedora18-1.x86_64.rpm | 68 MB 11:19
testing upgrade transaction
rpm transaction 100% [=========================================================]
rpm install 100% [=============================================================]
setting up system for upgrade
Finished. Reboot to start upgrade.
I think there is no need to disable third party repos, just to pay attention on the fedup messages. Fedup workaround is fine.
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.