Description of problem: I updated from kernel-3.0.1-3.fc16.x86_64 to kernel-3.1.0-0.rc2.git7.2.fc16.x86_64. But the update procedure did not update the echo line echo 'Loading Fedora (3.0.1-3.fc16.x86_64)' into echo 'Loading Fedora (3.1.0-0.rc2.git7.2.fc16.x86_64)' for the menu entry of kernel-3.1.0-0.rc2.git7.2.fc16.x86_64. That menu entry for kernel-3.1.0-0.rc2.git7.2.fc16.x86_64 is: menuentry 'Fedora (3.1.0-0.rc2.git7.2.fc16.x86_64)' --class fedora --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod part_msdos insmod ext2 search --no-floppy --label --set=root /F16 echo 'Loading Fedora (3.0.1-3.fc16.x86_64)' linux /boot/vmlinuz-3.1.0-0.rc2.git7.2.fc16.x86_64 root=LABEL=/F16 ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 KEYTABLE=de-latin1-nodeadkeys LANG=en_US.UTF-8 echo 'Loading initial ramdisk ...' initrd /boot/initramfs-3.1.0-0.rc2.git7.2.fc16.x86_64.img } and the menu entry of kernel-3.0.1-3.fc16.x86_64: menuentry 'Fedora (3.0.1-3.fc16.x86_64)' --class fedora --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod part_msdos insmod ext2 search --no-floppy --label --set=root /F16 echo 'Loading Fedora (3.0.1-3.fc16.x86_64)' linux /boot/vmlinuz-3.0.1-3.fc16.x86_64 root=LABEL=/F16 ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 KEYTABLE=de-latin1-nodeadkeys LANG=en_US.UTF-8 echo 'Loading initial ramdisk ...' initrd /boot/initramfs-3.0.1-3.fc16.x86_64.img Version-Release number of selected component (if applicable): kernel-3.1.0-0.rc2.git7.2.fc16.x86_64 How reproducible: Did not try! Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: The newer kernel is bootetd correctly!
The loading message is again correct with 3.1.0-0.rc3.git0.0.fc16.x86_64.
(In reply to comment #1) > The loading message is again correct with 3.1.0-0.rc3.git0.0.fc16.x86_64. Please reopen the bug! It's *not correct* that is has been solved by 3.1.0-0.rc3.git0.0.fc16.x86_64.
Reopened - I'm surprised Bugzilla doesn't let you reopen your own bug. Also set the Platform to "x86_64 Linux", since I can only vouch for it on x86_64, but it's likely it happens on i386 as well.
Created attachment 520038 [details] grub.cfg on affected F16 x86_64 system (always says "Loading Fedora (3.0.0-3.fc16.x86_64)")
Changing the Component to grubby based on the thread http://lists.fedoraproject.org/pipermail/test/2011-August/102191.html . On Rawhide, I used "grub2-mkconfig -o /boot/grub2/grub.cfg" to recreate grub.cfg, and after installing a new kernel, it was updated correctly, so I don't know if the bug even still exists. Also ran the same command on F16 but am waiting for a kernel update to see if it works properly there as well.
After the latest F16 kernel update, grubby updates correctly there as well. Anyone know if this bug is already fixed?
I am now seeing the wrong echo line in Rawhide for the latest kernel, so the bug still exists. The file grub.cfg was last modified yesterday at 11:26 (local time), just before booting into the new kernel which I had just installed. [root@localhost ~]# last -3 reboot reboot system boot 3.1.0-0.rc4.git0 Wed Aug 31 09:53 - 10:03 (00:09) reboot system boot 3.1.0-0.rc4.git0 Tue Aug 30 11:28 - 11:36 (00:08) reboot system boot 3.1.0-0.rc3.git5 Tue Aug 30 10:57 - 11:27 (00:30) wtmp begins Sat Aug 6 15:19:15 2011 [root@localhost ~]# Bad section of grub.cfg: menuentry 'Fedora (3.1.0-0.rc4.git0.0.fc17.x86_64)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod part_gpt insmod ext2 set root='(hd0,gpt2)' search --no-floppy --fs-uuid --set=root 35c75285-d5e2-4ff5-a487-6a31bae0c421 echo 'Loading Fedora (3.1.0-0.rc3.git5.0.fc17.x86_64)' linux /vmlinuz-3.1.0-0.rc4.git0.0.fc17.x86_64 root=/dev/mapper/VolGroup-lv_root ro SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-0.rc4.git0.0.fc17.x86_64.img }
I can confirm this.
Created attachment 523165 [details] loading.patch grub2-mkconfig will create lines like: echo 'Loading Linux 3.1.0-0.rc6.git0.0.fc16.x86_64 ...' grubby will correctly recognize these lines and replace them with lines with the right version number such as: echo 'Loading Fedora (3.1.0-0.rc6.git0.0.fc16.x86_64)' these lines are however not recognized by grubby and will not be updated next time. We need to update all the right kinds of 'Loading' messages to the new kernel version This patch makes sure that "'Loading Fedora " also is recognized and updated correctly. It could be argued that the extra parens are ugly and that grubby and mkconfig should emit the same output, but that's a different issue. Both kinds are out there in the wild and we have to handle both.
I'm seeing the same issue throughout rc4, rc5, rc6 kernels. It always shows "Loading ..." for the previously updated kernel. I.e. Loading rc6 echo rc5, loading rc5 echos rc4, etc.
This seems to be a duplicate of bugzilla #743119 or vice versa.
Patch available in bug #743119. *** This bug has been marked as a duplicate of bug 743119 ***
Reopened since essentially exactly the same patch was already available in this bug in comment 9.
*** Bug 743119 has been marked as a duplicate of this bug. ***
*** Bug 747542 has been marked as a duplicate of this bug. ***
Discussed at 2011-10-21 NTH review meeting. Agreed this is not an NTH issue; it has no actual practical impact and can be fixed safely with a post-release update. It doesn't affect initial install, because anaconda uses grub2-mkconfig, not grubby. This bug only happens when grubby is using an existing kernel entry as a template, which _only_ happens in post-install kernel updates.
*** Bug 749963 has been marked as a duplicate of this bug. ***
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 530798 [details] updated patch that doesn't hardcode the customizable title Update "echo 'Loading..." messages to the new kernel version grub2-mkconfig will create lines like: echo 'Loading Linux 3.1.0-0.rc6.git0.0.fc16.x86_64 ...' - depending on the content of /etc/default/grub. grubby would recognize these lines and replace them with lines with the right version number such as: echo 'Loading Fedora (3.1.0-0.rc6.git0.0.fc16.x86_64)' these lines were however not recognized by grubby and would not be updated on next kernel update when this entry would be used as template. With this patch grubby will no longer look for a specific title but patch any "echo 'Loading" line immediately before the kernel line.
*** Bug 751604 has been marked as a duplicate of this bug. ***
*** Bug 751601 has been marked as a duplicate of this bug. ***
*** Bug 755706 has been marked as a duplicate of this bug. ***
*** Bug 741847 has been marked as a duplicate of this bug. ***
*** Bug 757437 has been marked as a duplicate of this bug. ***
*** Bug 757198 has been marked as a duplicate of this bug. ***
*** Bug 757235 has been marked as a duplicate of this bug. ***
*** Bug 760596 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Created attachment 530798 [details] If there is some overriding issue with this patch, could we at least put in a patch to just not insert the "echo Loading ...." line at all? This way just makes it look like the incorrect kernel is being booted which is just not a very good thing at all.
*** Bug 761400 has been marked as a duplicate of this bug. ***
*** Bug 757406 has been marked as a duplicate of this bug. ***
Mads, can you attach an updated patch that's in a format "git am" will recognize?
it's okay, I'll do it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
grubby-8.3-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/grubby-8.3-2.fc16
Package grubby-8.3-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing grubby-8.3-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16908/grubby-8.3-2.fc16 then log in and leave karma (feedback).
(In reply to comment #35) > Package grubby-8.3-2.fc16: > * should fix your issue, > * was pushed to the Fedora 16 testing repository, > * should be available at your local mirror within two days. > Update it with: > # su -c 'yum update --enablerepo=updates-testing grubby-8.3-2.fc16' > as soon as you are able to. > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2011-16908/grubby-8.3-2.fc16 > then log in and leave karma (feedback). Do we know if there will be a kernel update soon? Or do I need to backout the most recent kernel version and re-update the kernel in order to test this?
https://admin.fedoraproject.org/updates/FEDORA-2011-16840/kernel-3.1.5-1.fc16
(In reply to comment #35) > Package grubby-8.3-2.fc16: > * should fix your issue, > * was pushed to the Fedora 16 testing repository, > * should be available at your local mirror within two days. > Update it with: > # su -c 'yum update --enablerepo=updates-testing grubby-8.3-2.fc16' > as soon as you are able to. > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2011-16908/grubby-8.3-2.fc16 > then log in and leave karma (feedback). Displays now the right echo line after updating to kernel-3.1.5-1.fc16.x86_64 and rebooting :-)
*** Bug 766057 has been marked as a duplicate of this bug. ***
grubby-8.3-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
bill: they usually come along fairly frequently, but you can just do a 'yum reinstall' if you want to test it right away. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This bug seems to walk the earth again in grub2-2.0-0.25.beta4.fc17.x86_64. It is translated now, so maybe this is the source of the problem: ### BEGIN /etc/grub.d/10_linux ### menuentry 'Fedora (3.4.0-1.fc17.x86_64)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-67681f12-ee66-41a0-b18e-feed75f27622' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='hd0,msdos3' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' ec9db239-05ec-4dd0-9f70-7ae8e00162d9 else search --no-floppy --fs-uuid --set=root ec9db239-05ec-4dd0-9f70-7ae8e00162d9 fi echo 'Wczytywanie systemu Linux 3.3.7-1.fc17.x86_64...' linux /vmlinuz-3.4.0-1.fc17.x86_64 root=/dev/mapper/vg_snowball2-lv_root ro rd.lvm.lv=vg_snowball2/lv_swap rd.md=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.lvm.lv=vg_snowball2/lv_root rd.luks=0 LANG=pl_PL.UTF-8 KEYTABLE=pl2 nouveau.modeset=0 rd.driver.blacklist=nouveau echo 'Wczytywanie początkowego dysku RAM...' initrd /initramfs-3.4.0-1.fc17.x86_64.img }
I have the same issue.
Same issue here with German localization on Fedora 17. Just updated to the 3.5.0 kernel, but the echo-line still mentions 3.4.6. # rpm -q grubby grubby-8.12-1.fc17.x86_64 menuentry 'Fedora (3.5.0-2.fc17.x86_64)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-[...]' { [...] echo 'Linux 3.4.6-2.fc17.x86_64 wird geladen …' linux /vmlinuz-3.5.0-2.fc17.x86_64 root=UUID=[...] echo 'Initiale Ramdisk wird geladen …' initrd /initramfs-3.5.0-2.fc17.x86_64.img }
F17, Ukrainian localization. Updated to kernel 3.5.2, in grub.cfg: echo 'Завантаження Linux 3.4.4-5.fc17.x86_64…' rpm -q grubby # rpm -q grubby grubby-8.12-1.fc17.x86_64
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.
I can confirm this problem on F18.
I can confirm this problem on F18, with a localized description.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 18'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.
No more such problem in F20; obviously fixed in F20