Bug 743977
| Summary: | /etc/grub2.cfg symlink is mostly useless and fragile | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | grub2 | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 33 | CC: | dennis, get.sonic, igeorgex, mads, mike, pjones, robatino, sergio, todoleza |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-12-31 11:02:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Michael Schwendt
2011-10-06 16:10:11 UTC
The symlink is needed by grubby. IMHO it is a bug in grub-mkconfig that it doesn't follow the symlink. (In reply to comment #0) > With > > $ rpm -q grub2 > grub2-1.99-6.fc16.x86_64 > > there is the /etc/grub2.cfg symlink to the actual config file: > > # rpmls grub2|grep ^l > lrwxrwxrwx /etc/grub2.cfg > # file /etc/grub2.cfg > /etc/grub2.cfg: symbolic link to `/boot/grub2/grub.cfg' > > This is mostly useless, because grub2-mkconfig doesn't follow this symlink but > replaces it with its output file: I don't agree , /etc/grub... is a default location of configuration like others components. when I edit grub2.cfg , I prefer do vi /etc/gru <tab> Sergio, that's why vi (and several other editors) follow the symlink. However, grub2-mkconfig does NOT follow the symlink, but kills it and replaces it with its output file, which is in a place where GRUB does NOT expect it.
My work-around has been this:
--- grub2-mkconfig.ORIG 2011-10-07 01:17:40.408130365 +0200
+++ grub2-mkconfig 2011-10-07 01:18:53.922155628 +0200
@@ -257,6 +257,9 @@
GRUB_BADRAM
if test "x${grub_cfg}" != "x"; then
+ if [ -L "${grub_cfg}" ] ; then
+ grub_cfg=$(readlink ${grub_cfg})
+ fi
rm -f ${grub_cfg}.new
exec > ${grub_cfg}.new
Alternative changes implement a while-loop to follow deeper symlinking.
(In reply to comment #3) I doubt a patch like this would be applied in the Fedora rpm. It would have to be upstreamed first. Upstream can however not use the patch because readlink isn't cross platform. Because of this symlink, I wasted several hours trying to get a manual entry in to the boot menu. I had no experience with grub2 and I found this /etc/grub2.cfg file. After reading a bit, I replaced it with grub2-mkconfig, but nothing happened. Several reboots and grub2-installs later, I stumbled up on this bug report. If the symlink is there (upstream doesn't require it, do they?), then it should work, or at least be useful. As of now, it does more harm than good. Since one is not supposed to edit it manually, one has to use grub2-mkconfig. And that when applied on this symlink only helps to make matters worse. The symlink is needed. It is used to point out which configuration file grubby should update. It is not surprising that working with grub2 (or boot loaders in general) without experience and without any documentation is hard and error prone. I think the primary lesson is that it always is important to be careful and read the documentation ... and that the documentation probably could be improved. Why can't 'grubby' directly use the file that matters? As far as I can see, grubby shouldn't have any problems with that. It'll use any file that you tell it to. You can't entirely pin this on not reading the manual. If there's a symlink, users expect it to not matter whether they are writing to the symlink or to the target file. Even if I had figured that /etc/grub2.cfg is a symlink, I still would have used grub2-mkconfig on it, expecting it to work. Why? Because it used to work with /etc/grub.conf and also because that's how symlinks are supposed to work. There's definitely a bug in grub2-mkconfig. Does it really have to 'rm' the file and then create it again? Can't it just overwrite? The way I see it, there are two bugs - one from Fedora (the existence of the symlink & grubby configuration to use it) and one from grub2-mkconfig (not following the symlink). > Does it really have to 'rm' the file and then create it again?
> Can't it just overwrite?
Much about this has been discussed on Fedora test list before. It doesn't 'rm' the file. It uses 'mv' to rename its final output file. Look at the end of /sbin/grub2-mkconfig. It doesn't have to do it that way, but one can defend the choice of using 'mv' with the goal of atomicity (even if there may be other factors that could cause the generated grub.conf to not work).
yesterday, after an upgrade from F15 to F16 with preuprade. I got a stress , because /etc/grub2.cfg was a copy of /boot/grub2/grub.cfg not a symbol link and I edit /etc/grub2.cfg and of course boot configuration doesn't update. Also notice that /etc/sysconfig/kernel is ignore cat /etc/sysconfig/kernel # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel I know this is off-topic but how I say to not update default boot configuration ? (In reply to comment #0) > # grub2-mkconfig -o /etc/grub2.cfg > Generating grub.cfg ... > ... > # ls /etc/grub2.cfg > /etc/grub2.cfg > # file /etc/grub2.cfg > /etc/grub2.cfg: ASCII English text > > The resulting /etc/grub2.cfg is not used at boot-time, of course. This doesn't > make sense, if this symlink cannot be used out of convenience. file /etc/grub2.cfg , should be /etc/grub2.cfg: symbolic link to `/boot/grub2/grub.cfg' and that is a bug grub2-mkconfig -o /etc/grub2.cfg doesn't change /boot/grub2/grub.cfg which is the file which is read at boot time. So with or without symbolic link , grub2-mkconfig should write on /boot/grub2/grub.cfg, which doesn't . Should I file a new bug ? The original description of this ticket points out that grub2-mkconfig _does not_ follow the symlink, but replaces it with a file. That's also what the "fragile" part of the subject line refers to. You only created an incomplete quote. (In reply to comment #11) > The original description of this ticket points out that grub2-mkconfig _does > not_ follow the symlink, but replaces it with a file. That's also what the > "fragile" part of the subject line refers to. You only created an incomplete > quote. hi, well subject says that is /etc/grub2.cfg symlink is mostly useless and fragile when should says that grub2-mkconfig _does not_ follow the symlink, but replaces it with a file. which is a big bug . (In reply to comment #12) > hi, well subject says that is /etc/grub2.cfg symlink is mostly useless and > fragile > when should says that grub2-mkconfig _does not_ follow the symlink, but > replaces it with a file. This report was obviously made when Michael was new to grub2 and had a frustrating experience figuring out how to deal with it in Fedora. The subject describes the frustration, not a specific bug. In my opinion this is NOTABUG. 1. symlinks are symlinks. Some tools will follow them and some tools won't. Watch out when symlinks are involved and know your tools. 2. grub2-mkconfig do not have special functionality for dealing with symlinks - just like for example mv. That might be intentional or not, but I don't think it qualifies as a big bug. 3. /etc/grub2.cfg is something Fedora uses to help grubby - it is not meant for grub2-mkconfig. Just forget about it. 4. the right way to invoke grub2-mkconfig manually is "grub2-mkconfig -o /boot/grub2/grub.cfg" - no documentation or folklore has ever recommended anything else (I hope). Anyway, I am sure that the only way to change the behaviour of grub-mkconfig is to contribute a patch upstream. (In reply to comment #13) > > In my opinion this is NOTABUG. I beg to differ. > > 3. /etc/grub2.cfg is something Fedora uses to help grubby - it is not meant for grub2-mkconfig. Just forget about it. This is the first problem. This file is not required by grub2 upstream and is used only for a tool 'grubby', which seems to be a Fedora project anyway. As far as I can see (from grubby documentation), it must not be mandatory to even have this symlink. > > 4. the right way to invoke grub2-mkconfig manually is "grub2-mkconfig -o > /boot/grub2/grub.cfg" - no documentation or folklore has ever recommended > anything else (I hope). With older grub, there used to be symlink at /etc/grub.conf. And as most other config files are in /etc, this kind of made sense and everything was merry. So people expect the same with grub2 symlink also. > > Anyway, I am sure that the only way to change the behaviour of grub-mkconfig is to contribute a patch upstream. The other option is to remove the symlink which doesn't add any value, but only helps to create more confusion. The way I see it, grubby (or the Fedora package) needs to be fixed if it refuses to use the grub2 upstream file and relies on a custom Fedora symlink. Well, /etc/grub2.cfg is not even mentioned in "man grubby" either. The page hardcodes /boot/grub/grub.cfg (bug 752505) and doesn't know GRUB2 at all [yet]. 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. *** Bug 1055104 has been marked as a duplicate of this bug. *** This problem remains in Fedora 33. I agree with Michael and several of the commentators here that the fragility of the symlink leads to difficulty and confusion when troubleshooting. Well, the original problem isn't reproducible anymore here. The symlink has been moved to a subpackage and has been made relative, and grub2-mkconfig doesn't replace it with a file anymore: $ rpm -qf /etc/grub2.cfg grub2-pc-2.04-31.fc33.x86_64 $ rpmls grub2-pc -rw-r--r-- /boot/grub2/grub.cfg drwx------ /boot/loader/entries lrwxrwxrwx /etc/grub2.cfg $ sudo file /etc/grub2.cfg /etc/grub2.cfg: symbolic link to ../boot/grub2/grub.cfg $ sudo grub2-mkconfig -o /etc/grub2.cfg Generating grub configuration file ... ... done $ sudo file /etc/grub2.cfg /etc/grub2.cfg: symbolic link to ../boot/grub2/grub.cfg |