Created attachment 588972 [details] The /boot after preupgrade, before I fixed it with re-running grub2-install Description of problem: First decribed in: https://bugzilla.redhat.com/show_bug.cgi?id=820351#c36 ----------------- error: file not found. error: file not found. error: file not found. Loading Linux 3.3.7-1.fc17.x86_64 ... Press any key to continue... ------------------ and also [Bug 826781 - 'File Not Found' on startup ] It appear that it is because preupgrade creates/modifies grub2.cfg without putting a new grub2 in. The main time stamps before are: /boot/extlinux Feb 15 18:39 /boot/grub2 Feb 3 02:27 /boot/grub2/themes/system May 9 20:13 grub2-1.99-13.fc16.3 Thu 10 May 2012 13:22:15 BST # du boot.bak/ 248 boot.bak/efi/EFI/redhat 252 boot.bak/efi/EFI 256 boot.bak/efi 4164 boot.bak/grub2/themes/system 4168 boot.bak/grub2/themes 4 boot.bak/grub2/locale 6252 boot.bak/grub2 4 boot.bak/lost+found 1360 boot.bak/extlinux 352 boot.bak/grub 72720 boot.bak/ after running grub2-install, # du /boot 338 /boot/grub 244 /boot/efi/EFI/redhat 246 /boot/efi/EFI 248 /boot/efi 13 /boot/lost+found 1316 /boot/extlinux 1908 /boot/grub2/i386-pc 4115 /boot/grub2/themes/system 1930 /boot/grub2/themes/starfield 6047 /boot/grub2/themes 2426 /boot/grub2/locale 2504 /boot/grub2/fonts 12930 /boot/grub2 105037 /boot Not the new directory "i386-pc". the problem is gone. (replaced by Bug 817187 - GRUB2 error: file '/boot/grub2/locale/en.mo.gz' not found ). Version-Release number of selected component (if applicable): grub2-1.99-13.fc16.3 installed on Thu 10 May 2012 13:22:15 BST grub2-2.0-0.25.beta4.fc17.x86_64 How reproducible: Once for me - but it seems to be a widely experienced problem, see [Bug 826781 - 'File Not Found' on startup ] and https://bugzilla.redhat.com/show_bug.cgi?id=820351#c41 and elsewhere. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: The /boot after preupgrade, before I fixed it with re-running grub2-install, is attached with: tar -czpvf /tmp/oldboot.tgz --exclude "initramfs*" --exclude "vmlinu*" --exclude "xen-sym*" boot.bak (to skip a few large not interesting files).
(In reply to comment #0) > Version-Release number of selected component (if applicable): > grub2-1.99-13.fc16.3 installed on Thu 10 May 2012 13:22:15 BST > grub2-2.0-0.25.beta4.fc17.x86_64 What does that mean? Do you have both grub2 versions installed after upgrading? Please attach your anaconda log files.
grub.cfg shows that these things happened in this order: 1. f16 grub2 was installed 2. kernel 3.3.7-1.fc17.x86_64 was installed 3. grub2-mkconfig was run 4. kernel 3.3.7-1.fc17.x86_64 was installed again Hin-Tak Leung, are you 100% sure you didn't do anything manually that can have caused this?
(In reply to comment #2) > grub.cfg shows that these things happened in this order: > 1. f16 grub2 was installed > 2. kernel 3.3.7-1.fc17.x86_64 was installed > 3. grub2-mkconfig was run > 4. kernel 3.3.7-1.fc17.x86_64 was installed again > > Hin-Tak Leung, are you 100% sure you didn't do anything manually that can > have caused this? That sounds pausible - 3. was possibly a side-effect of 2.? I filed this bug because grub2-install (which would have put *f17* grub2 on) was never run at any time - so I seemed to have ended up with a f17-lookalike grub2.cfg against f16 grub2, which causes the symptom of three "error: file not found.". Preupgrade got me 1,2 and possibly also 3, and I ended up with a non-bootable f17 kernel initramfs (filed as "bug 827997 preupgrade makes non-usable initramfs"), this I install 3.3.7-1.f17 manually to fix. My point of this bug report is that *f17* grub2 was installed to the system at some point by preupgrade, but was never put into /boot, although it should be.
I also had this problem after doing a preupgrade from 16 -> 17 (accepting all the defaults) and then encountering bug 822760. After running the following two commands as described in that bug, I ran into the three 'file not found' errors: sudo dracut -f sudo grub2-mkconfig -o /boot/grub2/grub.cfg Running 'sudo grub2-install /dev/sda' then solved those three errors for me.
(In reply to comment #3) > My point of this bug report is that *f17* grub2 was installed to the system > at some point by preupgrade, but was never put into /boot, although it > should be. A grub2 package update will update the tools and make a new bootloader version available for installation in /boot and MBR. Installation in /boot and MBR is however a separate and slightly dangerous task that "never" is done automatically by package installation. Anaconda might however do it when it perform the upgrade. You are right that a preupgrade upgrade doesn't run grub2-install - as explained by Adam in https://bugzilla.redhat.com/show_bug.cgi?id=826537#c27 . That is probably not intentional and it is different from all other upgrade methods and should thus be considered a bug. With grubby being fixed it is however no longer a serious bug. A preupgrade do however also not run grub2-mkconfig but leave the system in a consistent state. The message "error: file not found." must be caused by you manually running grub2-mkconfig without manually running grub2-install first. Preupgrade in f16 should ASAP be updated with something like: --- /usr/lib/python2.7/site-packages/preupgrade/__init__.py +++ __init__.py @@ -595,11 +595,11 @@ 'grubby --remove-kernel=%s' % kernel, 'rm -rf %s /var/cache/yum/preupgrade*' % self.bootpath, '%end\n'] - # Fedora 16 switched to grub2 - if float(self.source_version) < 16.0 and float(self.target_version) >= 16.0: - ks[3] += ' --location=mbr' - else: - ks[3] += ' --upgrade --location=none' + # grub2 is currently a moving target - installation is better than upgrade + #if float(self.source_version) < 16.0 and float(self.target_version) >= 16.0: + ks[3] += ' --location=mbr' + #else: + # ks[3] += ' --upgrade --location=none' if float(self.target_version) > 10.0: ks[5] += ' --root-device=UUID=%s' % dev.device_to_uuid('/dev/root') f.write('\n'.join(ks))
(In reply to comment #5) > A preupgrade do however also not run grub2-mkconfig but leave the system in > a consistent state. The message "error: file not found." must be caused by > you manually running grub2-mkconfig without manually running grub2-install > first. I have not manually run grub2-mkconfig (at least not when the attached /boot was archived). Surely one of the side effect of installing a new kernel is put a new entry in /boot/grub2/grub.cfg somehow? That must be part of a new kernel's post-install script?
The new kernel entry was put in place by grubby when the kernel was installed ... except that it didn't because of a grubby bug that since has been fixed. The original grub.cfg will tell if that is what happened if you attach it. Looking briefly at anaconda it seems like it perhaps in some cases actually could run grub2-install without grub2-mkconfig - not the opposite. Your anaconda logs will tell what it did if you attach them as text/plain. In any case: preupgrade should instruct anaconda to run both.
Mads: "That is probably not intentional and it is different from all other upgrade methods and should thus be considered a bug." Well...not really. History: Prior to the grub2 switch - all the way up to F15, at least from F11 or so when I came in - the default bootloader option on upgrade via DVD / netinst was 'update bootloader configuration': exactly what preupgrade does from 16->17, add new kernels to the grub config file but do not re-install grub. When F16 came out with the grub2 switch, we wanted to have systems switched to grub2 on upgrade, so we changed the default on upgrade in anaconda to 'install new bootloader', and adjusted preupgrade to do the same thing. But at the time it was assumed that we'd go back to 'update bootloader configuration' for later releases, since that had been the default for so long, and 15->16 was a 'special case' to get the grub2 upgrade done. So the logic that was put in preupgrade says 'do "install new bootloader" if upgrading from <16 to 16; otherwise, do 'update bootloader configuration'". That was quite intentional, not a bug. The discrepancy comes because anaconda team never got around to going back to 'update bootloader configuration' for anaconda upgrades from 16->17. I did suggest it several times but it was never a high priority issue. There is a question whether it would be better to stick with 'install new bootloader' on upgrades with grub2, since grub2 is much less stable than grub-legacy and you can end up in the situation where the grub.cfg from the previous release doesn't really 'match' the installed grub2 package. However, the drawback of 'install new bootloader' is that we never really know where to _put_ it. preupgrade is unattended, so we can't ask the user like we do on first install; what happens in practice is we just take a guess at 'MBR of /dev/sda'. This is correct most of the time, but certainly not _all_ the time. So some people with advanced bootloader setups get their setups nerfed by preupgrade, when doing 'install new bootloader'. Even in a DVD/netinst upgrade, which is interactive, we don't in practice give you enough flexibility over where to put the bootloader, because we don't pop up the diskfilter screen in an upgrade. All you get is the other bootloader location screen, which lets you pick the MBR of the first valid target drive, or the first partition of any drive - but you can't use it to pick the MBR of any other drive. So there are definitely drawbacks to both approaches; it's not a clear-cut choice. We might be better off sticking with 'update bootloader configuration'.
(In reply to comment #8) <snipped> > There is a question whether it would be better to stick with 'install new > bootloader' on upgrades with grub2, since grub2 is much less stable than > grub-legacy and you can end up in the situation where the grub.cfg from the > previous release doesn't really 'match' the installed grub2 package. <snipped> This is the problem of a few issues encountered - grub2's cfg format has evolved slightly and somewhat incompatibly within the fedora time scale of 6 months. Is it possible to prompt the user to update the boot loader configuration at the end of the reboot, or at least show a reminder, telling the user that it might be a good idea to reinstall the boot loader (and that it is not auto-done for him/her) ? That is, assuming one can go through to the end of the preupgrade... (got interrupted and plagued with a few problems on the way...).
(In reply to comment #8) Thank you for the clarification. FWIW I "agree" with your description of history and how the f17 DVD/netinst behaviour wasn't intentional. But 1. Having _different_ behaviour between DVD/netinst and preupgrade was also not the intention. I think it is reasonable to expect that all installers give the same result. I consider it a bug that they are different. 2. grub2 changed so much from f16 that reinstallation of the bootloader for f17 actually was (and is) necessary. Just one clarifying question: what will 'update bootloader configuration' do? Will it run grub2-mkconfig or will it just let grubby do its job?
I'm not sure. I can't actually figure out what self(update) does for grub2, from pyanaconda/bootloader.py . pjones may know.
Removing CommonBugs. Please add again if this also happens in Fedora 18.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.