Description of problem: After the first installation and the first kernel update I ended up with a non-bootable system, because /boot/grub2/grub.cfg was corrupted. Closer inspection revealed that grubby forgets the trailing '{' add each newly generated menuentry line. Version-Release number of selected component (if applicable): grubby-8.10-1.fc17.x86_64 grub2-1.99-19.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. update kernel package 2. inspect /boot/grub2/grub.cfg 3. Actual results: trailing '{' missing in menuentry line. grub2 fails to parse the configuration file and stops, leading to an unbootable system. Expected results: correctly updated /boot/grub2/grub.cfg Additional info:
suggested by adamw
BTW: after each kernel update I recompile the latest git HEAD for the nouveau/drm/ttm modules against it and update the initrd.img with /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update <new kernel version> I copied this command straight out of kernel's posttrans scriptlet. Maybe the --update functionality is broken?
Could you please, if possible, attach the grub2.cfg file as it existed before the bad update, and then as it existed after the bad update? (Or can anyone else who's hit this bug do the same)? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 571764 [details] grub2.cfg before running new-kernel-pkg
Created attachment 571766 [details] grub2.cfg after running new-kernel-pkg Executed command: /sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.3.0-1.fc17.x86_64 i.e. I just refreshed the currently active kernel.
I have a nearly identical grub.cfg after update with the inserted/modified menuentry lines lacking { at the end. GRUB stumbles through the cfg until it finds the first entry that is properly bracketed and executes, which happens to be the old kernel.
This bug obviously is "just a typo" [or similar], but "defensive parsing" has been around for decades, and does not require excessive space. In particular, the occurrence of keywords such as 'load_video' or 'insmod' (etc.) should terminate a 'menuentry'.
Created attachment 571778 [details] after updating to kernel 3.3.0-1
I think this is caused by the new fancy 'nested' layout grub2-mkconfig generates in the new grub2 (2.00-beta2). I can't reproduce this on my desktop, which still has the old-style grub2.cfg since I haven't manually run grub2-mkconfig after the update, but can reproduce in a VM which was installed with the new grub2 and hence got the nested layout. I'll attach my pre and post configs. grubby does, indeed, miss out the { that should terminate the 'menuentry' line, for the new entry. I think we could maybe consider this a more general bug, though, that grubby ought to be doing something rather different for the new grub2.cfg layout. It should add a new entry to the 'Advanced options for Fedora Linux' submenu and *update* the 'Fedora Linux' entry to point to the new kernel, right? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 571799 [details] grub2.cfg before munging by grubby
Created attachment 571800 [details] grub2.cfg after munging by grubby: using grubby 8.8-3
I just tested with grubby 8.10 from updates-testing. good news! it's even worse. it ditches rather more {s, breaking even more of the entries. Attaching that config.
Created attachment 571804 [details] grub2.cfg after munging by grubby: using grubby 8.10-1 Here's grub2.cfg after doing a kernel update with grubby 8.10-1 installed. it's somewhat worse than 8.8-3.
This happs also if kernel is removed with yumex. With grub2-mkconfig -o /boot/grub2/grub.cfg then it ok again. See atthachments after removing kernel with yumex and after grub2-mkconfig. Version-Release number of selected component (if applicable): grub2-1.99-19.fc17.x86_64 grubby-8.10-1.fc17.x86_64 yumex-3.0.4-2.fc17.noarch yum-3.4.3-18.fc17.noarch
Created attachment 571810 [details] grub after removing kernel with yumex grub after removing kernel with yumex
Created attachment 571811 [details] grub after grub2-mkconfig -o /boot/grub2/grub.cfg grub after grub2-mkconfig -o /boot/grub2/grub.cfg
grubby-8.11-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/grubby-8.11-1.fc17
So, I did some testing with 8.11. Broadly, here's what happens. The way I'm testing is to start from a base with kernel 3.3.0-1.fc17 installed, and an entirely clean grub2.cfg as produced directly from installation with just that kernel installed - installation was with grub2 1.99-19, so it has the 'nested' layout. This is the attachment listed as "grub2.cfg before munging by grubby" above. It contains a 'Fedora Linux' entry which doesn't do anything smart but is actually just a straight call to the 3.3.0-1 kernel and initramfs, and an 'Advanced options for Fedora Linux' submenu. This has one entry which is a straight listing for the 3.3.0-1 kernel, and one entry which is the same thing only in 'rescue mode'. The first test I try is just to install a new kernel, 3.3.0-3.fc17. With 8.8 and 8.10, this results in a substantially messed up config file with several entries that fail to boot, as discussed so far and shown in my "grub2.cfg after munging by grubby: using grubby 8.8-3" and "grub2.cfg after munging by grubby: using grubby 8.10-1" attachments. With 8.11-1, the result is a broadly valid grub2.cfg which boots 3.3.0-3.fc17 by default, so broadly, things are okay. It's clearly not exactly how upstream envisaged the menu looking, though. What you wind up with is a new entry for the 3.3.0-3.fc17 kernel *above* the 'Fedora Linux' and 'Advanced options for Fedora Linux' entries. These other entries are all untouched: they are exactly as described above. They all still boot 3.3.0-1.fc17. I will attach this grub2.cfg as "grub2.cfg after munging by grubby: using grubby 8.11-1". I then tried a further step - I yum remove'd kernel 3.3.0-1.fc17. This actually behaved somewhat better than I was worried it would. The 'Fedora Linux' entry gets removed, as do each of the two entries in the 'Advanced options for Fedora Linux' submenu. That submenu still 'exists' as a kind of stub in the config file, but it's apparently not a 'valid' stub, as it doesn't get shown at all in the actual menu presented to the user on bootup. What you actually see when booting is, quite simply, a single entry for 3.3.0-3.fc17. So in the end, the behaviour - though ever so slightly 'skewiff' - is broadly within the parameters we want, so far as I've tested. After installing a new kernel you get the new kernel by default, but you can still boot the old ones (though the menu entry names don't really *indicate* this). After removing the old kernel, all entries that point to it are removed. I'm just slightly worried that there may be other consequences to this slight 'culture clash' between how grub2-mkconfig operates and how grubby operates which don't show up in this fairly simple test but may show up in more complex configurations.
Created attachment 571822 [details] grub2.cfg after munging by grubby: using grubby 8.11-1 This is what you get on the first additional kernel install with grubby 8.11-1.
Created attachment 571823 [details] grub2.cfg after removing the initial kernel, using grubby 8.11-1 This is the grub2.cfg you get if you start at "grub2.cfg after munging by grubby: using grubby 8.11-1" and do 'yum remove kernel-3.3.0-1.fc17.x86_64'. It's slightly whacky, but it works.
I vote +1 NTH, -1 blocker on this, now its consequences are well understood: it messes up post-install kernel updates, and taking it as a post-beta update isn't totally ideal, but it's actually unlikely to ever leave the system completely unbootable so I don't think it's strictly a blocker. But we should definitely take the fix.
(In reply to comment #18) > It's clearly not exactly how upstream > envisaged the menu looking, though. What you wind up with is a new entry for > the 3.3.0-3.fc17 kernel *above* the 'Fedora Linux' and 'Advanced options for > Fedora Linux' entries. Basically it's sneezing entries all over the grub menu. It's immediately messy and confusing. I don't like it. It's icky UI. If the GRUB menu were hidden by default, I'd feel better about the crusty mess appearing behind the scene, but anyone who stumbles on that menu before it gets cleaned up is going to have a bit of a WTF moment. > I yum remove'd kernel 3.3.0-1.fc17. This actually > behaved somewhat better than I was worried it would. The 'Fedora Linux' entry > gets removed, as do each of the two entries in the 'Advanced options for Fedora > Linux' submenu. So only upon a, what, 3rd kernel being installed do we get an old kernel automatically removed and hence a clean up of the grub.cfg, which is still messier than how it started out upon a fresh install. *sigh* It's like helping a 3 year old blow their nose.
chris: yeah, that's how I read it. after three kernel updates you'll wind up with a simple old-school menu that just lists kernels. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
If somebody wanted to write a patch that stores the line number of the "default" template and inserts the new menu entry at the same place, I'd be happy to review and test it.
+1 NTH, -1 beta blocker.
+1 NTH, -1 blocker
three matching votes, accepted as Beta NTH, rejected as blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
+1 NTH (hopefully before the first post freeze kernel update) -1 blocker
bruno: 'hopefully' depends on it getting karma. ;) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
see my comment on bodhi: my test case now works OK.
grubby-8.11-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.