Created attachment 684577 [details] fedup log file Description of problem: Running fedup to prepare for F17->F18 upgrade completes without errors or warnings, but no upgrade entry is created in /boot/grub2/grub.cfg (file is not modified according to timestamp). Version-Release number of selected component (if applicable): fedup-0.7.2-1.fc17.noarch (also using grub2-2.0-0.39.fc17.x86_64) How reproducible: Alyways Steps to Reproduce: 1. fedup --network 18 2. check /boot/grub2/grub.cfg for upgrade boot entry 3. check timestamp of /boot/grub2/grub.cfg Actual results: No upgrade boot entry in grub.cfg. File not changed. Expected results: Expect to find an "Upgrade to F18" entry in the boot menu. Additional info: Not sure this is related, but it makes the affected machine a bit special. This system has been upgraded all the way back since FC3 (in single-version increments.) Anyway, the original boot partition was 100MB, which is now officially no longer enough to upgrade (Thanks to whoever came up with that number as the default boot partition size!). To address the issue, I created a new /boot directory in the root file system, copied the contents of the original boot partition there, and re-ran "grub2-install". Then I removed the original boot partition from /etc/fstab. The new /boot directory has gone through one kernel upgrade and several reboots without a problem, so it is fully functional. Also, I checked the original (still existing) /boot partition, just in case fedup for some reason is trying to create a boot entry in the grub.cfg file there, but there is no change to any files on that partition either. So I don't think this is related to the problem, but thought I'd better mention it.
Created attachment 684578 [details] The /boot/grub2/grub.cfg file - unchanged by fedup This is the grub.cfg file, both before and after running fedup (no change is made by running fedup).
I am also having the same problem on multiple machines. New kernels sometimes have no entry in the grub.cfg file (and sometimes do!). This totally messed me up on the laptop as I removed the old kernel and was left with an empty grub.cfg file.......not fun.
Sammy - I don't think this is the same problem. All my kernel updates have always resulted in proper entries added to the grub.cfg. My problem is very specific to fedup. (In reply to comment #2) > I am also having the same problem on multiple machines. New kernels > sometimes have no entry in the grub.cfg file (and sometimes do!). This > totally messed > me up on the laptop as I removed the old kernel and was left with an empty > grub.cfg file.......not fun.
Did you properly start the upgrade? Start the upgrade prep by executing following command sudo fedup-cli --network 18 --debuglog fedupdebug.log Once the preparations have completed, check the fedupdebug.log file if any errors show up in the output from fedup- as explained in http://fedoraproject.org/wiki/FedUp
That's exactly what I did - I only used "fedup" instead of "fedup-cli" and added "--debug" and "--verbose" to the command. To be sure, I just repeated with your exact command line, and the result is exactly the same: no entry in grub.cfg, no error in the fedup log file. Will attached the log file once again, just in case. (In reply to comment #4) > Did you properly start the upgrade? > > Start the upgrade prep by executing following command > sudo fedup-cli --network 18 --debuglog fedupdebug.log > Once the preparations have completed, check the fedupdebug.log file if any > errors show up in the output from fedup- > > as explained in http://fedoraproject.org/wiki/FedUp
Created attachment 686981 [details] Another fedup log file from running "fedup-cli" rather than "fedup"
fedup adds the boot entry by running: new-kernel-pkg --initrdfile /boot/initramfs-fedup.img \ --banner 'System Upgrade' \ --kernel-args 'upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0' \ --make-default \ --install fedup (possibly adding "selinux=0" to kernel-args instead, if SELinux is disabled) What happens if you run that command by hand?
I get grubby fatal error: unable to find a suitable template which I suppose would explain why no entry is created. (In reply to comment #7) > fedup adds the boot entry by running: > > new-kernel-pkg --initrdfile /boot/initramfs-fedup.img \ > --banner 'System Upgrade' \ > --kernel-args 'upgrade systemd.unit=system-upgrade.target > plymouth.splash=fedup enforcing=0' \ > --make-default \ > --install fedup > > (possibly adding "selinux=0" to kernel-args instead, if SELinux is disabled) > > What happens if you run that command by hand?
This is a grubby bug, then. Can you please attach your /etc/grub2.cfg (or /boot/grub2/grub.cfg - they should be the same file)?
That file is already attached to the bug. (In reply to comment #9) > This is a grubby bug, then. > > Can you please attach your /etc/grub2.cfg (or /boot/grub2/grub.cfg - they > should be the same file)?
Latest on this matter - did some digging in the Fedora forums and found suggestions to run grub2-mkconfig -o /boot/grub2/grub.cfg in case of grubby errors. Did this, and now the upgrade kernel is there. Also, after running the above, I can now run the new-kernel-pkg command suggested by Will without getting an error.
This is happening all the time...very annoying, kernel installed no entry in /boot/grub2/grub.cfg I ran the command by hand: # /sbin/new-kernel-pkg -v --package kernel-3.7.8-202.fc18.x86_64.rpm --install 3.7.8-202.fc18.x86_64 initrdfile is /boot/initrd-3.7.8-202.fc18.x86_64.img /etc/grub.conf does not exist, not running grubby for grub 0.97 adding 3.7.8-202.fc18.x86_64 to /boot/grub2/grub.cfg grubby fatal error: unable to find a suitable template /etc/grub2-efi.cfg does not exist, not running grubby for grub 2 with UEFI /etc/lilo.conf does not exist, not running grubby /etc/extlinux.conf does not exist, not running grubby for extlinux If I run grub2-mkconfig it correctly creates the grub.cfg....
Was /boot mounted at the time? Are all the kernels listed in grub.cfg present and readable? What does grub.cfg look like after it's "fixed" by running grub2-mkconfig? Can someone attach a bad config and the resulting fixed config?
Yes, /boot is always mounted isn't it? This is a clean DVD install of Fedora 18. I am attaching grub.cfg after running grub2-mkconfig I don't have the older one but it looks just the same. Using this attached grub.cfg when I try to install the next kernel it will still give me the same error. And not I still get the error in Comment 12. also, /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora_dhcp-129-59-117-21/root rd.lvm.lv=fedora_dhcp-129-59-117-21/swap rhgb quiet LANG=en_US.UTF-8 selinux=0 nouveau.modeset=0 rd.driver.blacklist=nouveau" GRUB_DISABLE_RECOVERY="true" GRUB_THEME="/boot/grub2/themes/system/theme.txt"
Created attachment 698275 [details] grub.cfg after
OK. Here is what found on multiple systems: The problem seems to have to do with /etc/mtab contents. Not clear what. But if I do 'cat /proc/mounts > /etc/mtab' then the kernel updates work just fine, namely the template is found. Tried on three different systems, two desktops and a laptop. FYI
Comment 9 was the key in my case; at some point, /etc/grub2.cfg stopped being a link to /boot/grub2/grub.cfg. The side effect was that grubby kept updating /etc/grub2.cfg but that doesn't help during boot. Oh, and the problem with "grubby fatal error: unable to find a suitable template" is discussed in Bug 730357, in my case having left-over /etc/grub.cfg and /boot/grub/grub.cfg files.
(In reply to Sammy from comment #16) > OK. Here is what found on multiple systems: > The problem seems to have to do with /etc/mtab contents. Not clear what. > But if I do 'cat /proc/mounts > /etc/mtab' then the kernel updates work > just fine, namely the template is found. Tried on three different systems, > two desktops and a laptop. > FYI I get the following error: # cat /proc/mounts > /etc/mtab cat: /proc/mounts: input file is output file
I have attempted to upgrade to f19 with fedup --network 19. After rebooting there what no upgrade and the inspection of the system show that the last kernel (vmlinuz-3.9.6-200.fc18.x86_64) is also not present within grub2, the system load always the previous kernel (vmlinuz-3.9.5-201.fc18.x86_64). According to this the problem seem not to be within fedup.
(In reply to Jean-Jacques Sarton from comment #19) > I have attempted to upgrade to f19 with fedup --network 19. After rebooting > there what no upgrade and the inspection of the system show that the last > kernel (vmlinuz-3.9.6-200.fc18.x86_64) is also not present within grub2, the > system load always the previous kernel (vmlinuz-3.9.5-201.fc18.x86_64). > According to this the problem seem not to be within fedup. Same here. It appears all of the problems I have recently with boot/kernel configuration have all common cause, unknown https://ask.fedoraproject.org/question/27266/how-to-change-grub-2-boot-order/ https://ask.fedoraproject.org/question/27478/kernel-wont-update-how-to-fix-it/
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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 change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
I'm usign Fedora 18. With fedup to F19 I have the same problem. The entry is present in /etc/grub2.cfg I resolved with cp /etc/grub2.cfg /boot/grub2/grub.cfg rm /etc/grub2.cfg ln -s /boot/grub2/grub.cfg /etc/grub2.cfg
On my system /etc/grub2.cfg what already a link to /boot/grub2/grub.cfg. I had resolved the problem while inserting the entry for the latest F18 kernel, rebooting and runnning 'fedup --network 19 -d -v'. The log has shown that a few packages what installed and then the entry for the system upgrade what present within grub.cfg
Tried going from fc18 to 19 today. Used 'fedup-cli --network 19' Downloaded a boat-load of files, then just hung. Restarted, looked at /var/log/fedup.log ... it ended with "RpmDBError: Package tuple (bla-bla) could not be found .." Ran 'yum clean all', then 'yum -y update', worked fine. Then ran 'fedup-cli --network 19' again, and it said I was up to date. BUT - grub still doesn't have the fc19 offering. Ran 'grub2-mkconfig' ... no difference in grub.cfg also: ( /etc/grub2.cfg -> /boot/grub2/grub.cfg )
(In reply to Randy from comment #24) > Tried going from fc18 to 19 today. Used 'fedup-cli --network 19' > > Downloaded a boat-load of files, then just hung. Restarted, looked at > /var/log/fedup.log ... it ended with "RpmDBError: Package tuple (bla-bla) > could not be found .." > > Ran 'yum clean all', then 'yum -y update', worked fine. > > Then ran 'fedup-cli --network 19' again, and it said I was up to date. > > BUT - grub still doesn't have the fc19 offering. > > Ran 'grub2-mkconfig' ... no difference in grub.cfg > > also: > ( /etc/grub2.cfg -> /boot/grub2/grub.cfg ) For me the way what to manually edit grub.cfg (entry for last F18 kernel), rebooting and then to call fedup --network 19. May be that the problem you have is similar. While executing the last fedup command some more packages what downloaded.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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.
I'm reproducing this on f19. I'll attach my grub.cfg file...
Created attachment 867165 [details] Existing f19 grub.cfg that grubby balks on I get: grubby fatal error: unable to find a suitable template when I try: new-kernel-pkg --initrdfile /boot/initramfs-fedup.img \ --banner 'System Upgrade' \ --kernel-args 'upgrade systemd.unit=system-upgrade.target plymouth.splash=fedup enforcing=0' \ --make-default \ --install fedup
If I run this with -v, I get: initrdfile is /boot/initramfs-fedup.img found /boot/initramfs-fedup.img and using it with grubby /etc/grub.conf does not exist, not running grubby for grub 0.97 adding fedup to /boot/grub2/grub.cfg grubby fatal error: unable to find a suitable template /etc/grub2-efi.cfg does not exist, not running grubby for grub 2 with UEFI /etc/lilo.conf does not exist, not running grubby /etc/extlinux.conf does not exist, not running grubby for extlinux still not sure what causes the fatal error, however.
Seems that I've caught same problem on upgrading F19 to F20. Used `grub2-mkconfig -o /boot/grub2/grub.cfg` and call to `new-kernel-pkg` to fix this.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.