After removing .rc8 kernel, I'm left with: # # DO NOT EDIT THIS FILE # # It is automatically generated by grub2-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### if [ -s $prefix/grubenv ]; then load_env fi set default="0" if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { insmod vbe insmod vga insmod video_bochs insmod video_cirrus } set timeout=5 ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/10_linux ### menuentry 'Fedora (3.1.0-0.rc9.git0.0.fc16.x86_64)' --class gnu-linux --class gnu --class os { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod ext2 set root='(hd1,msdos1)' search --no-floppy --fs-uuid --set=root 37525b59-2458-4117-82ac-b3f5e70b20dc echo 'Loading Fedora (3.1.0-0.rc9.git0.0.fc16.x86_64)' linux /vmlinuz-3.1.0-0.rc9.git0.0.fc16.x86_64 root=UUID=a846cda4-53e5-46f7-a4a6-6294def2f423 ro quiet rhgb SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=croat echo 'Loading initial ramdisk ...' initrd /initramfs-3.1.0-0.rc9.git0.0.fc16.x86_64.img } i.e. everything after that is stripped. While I personally don't care too much about it since everything works OK without, it is probably a bug so I'm reporting it here.
That must have been done by grubby. Did you see any error messages when removing the kernel? Can you reproduce the problem and show how grub.cfg looked before?
Yes, I can reproduce it every time. There are no error messages on the console. I will attach the files.
Created attachment 529920 [details] grub.cfg before
Created attachment 529921 [details] grub.cfg after
Also, it's not Xen related. On another machine without Xen installed it strips all the content after the kernel entry.
I assume these configs were before and after removing 3.1.0-0.rc9.git0.0.fc16.x86_64. Grubby apparently assumed that the removed entry included the start of the submenu that followed it and it thus created a config file with invalid syntax. That might be a different bug. Can you show similar config files for a non-Xen machine?
Created attachment 529970 [details] grub.cfg before (no Xen) This is how it would look without Xen before
Created attachment 529971 [details] grub.cfg after (no Xen) This is how it would look without Xen after Whether it's Linux entries (generated by grub2-mkconfig) or Fedora entries doesn't change anything. These files are not real (they are modified versions of files I posted previously) since I didn't back up grub.cfg files on machine without Xen where I had this issue. But this is really how they looked.
(In reply to comment #6) > I assume these configs were before and after removing > 3.1.0-0.rc9.git0.0.fc16.x86_64. Grubby apparently assumed that the removed > entry included the start of the submenu that followed it and it thus created a > config file with invalid syntax. That might be a different bug. This is now tracked on Bug 748551. (In reply to comment #7) > Created attachment 529970 [details] > grub.cfg before (no Xen) > > This is how it would look without Xen before Thanks, but I haven't been able to reproduce any problem with grubby on this grub.cfg. Can you reproduce the problem?
Yes, it still happens. I will attach the files.
Created attachment 530376 [details] grub.cfg with 3 kernels
Created attachment 530377 [details] grub.cfg after removing one kernel
Created attachment 530378 [details] grub.cfg after removing two kernels
By the way, why don't the scripts just re-run # grub2-mkconfig -o /boot/grub2/grub.cfg after each kernel installation/removal? It does the job just fine.
(In reply to comment #11) > Created attachment 530376 [details] > grub.cfg with 3 kernels Ok, this first grub.cfg is bogus. Do you have any idea how the custom.cfg handling ended up inside the kernel entries? (In reply to comment #14) > By the way, why don't the scripts just re-run > > # grub2-mkconfig -o /boot/grub2/grub.cfg > > after each kernel installation/removal? It does the job just fine. Yes, that would be a different of doing it. The Fedora way of doing it is however to use grubby no matter which boot loader is used.
Created attachment 530483 [details] use dummy entries for text following kernel entries so it is preserved Now I don't understand how it was possible for me to _not_ reproduce the issue ;-) It is not related to the malformed kernel entry.
Hi, does this mean this bug is fixed? Please get this into final release of Fedora 16 if anyhow possible.
No, it is waiting for the package maintainer to pick it up.
Hi Adam, I saw you pushed an update to grubby on Koji. This is probably still na issue in F17 and certainly in F16. Could you please take a look if this patch is acceptable?
I'm not really qualified to review the patch, I'm just pushing out work that I know is acceptable to F16. I'm happy to do the work of integrating the patch into grubby and pushing an update, but I'd prefer it if pjones would take a look and ack or nack it first. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This patch looks good to me.
I've committed it to grubby 'upstream', I'll wait on the other currently proposed change (https://bugzilla.redhat.com/show_bug.cgi?id=742720 ) before cutting a new grubby release and pushing it to rawhide. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This seems to work now.