Description of problem: logs 110 lines of mostly debug info at each invocation showing tha tthe cncept of os-prober and grub2 is not yet ready for prime time as basic functions are not yet available yet logging overwhelms even the admins. Version-Release number of selected component (if applicable): os-prober-1.55-1.fc17.x86_64 How reproducible: os-prober tail -111 /var/log/messages Actual results: Loads of logging. Expected results: 1% of the actual logging Additional info: Rather I'd see no logging at all unless something really goes wrong. os-prober lacks a man page, does not have built-in help so I did NOT find a way to reduce the logging to zero. os-prober runs as part of `grub2-mkconfig -o /boot/grub2/grub.cfg` which makes this tool unavoidable despite the lack of basic grub features in grub2, despite the lack of userfriendliness of grub2 because in some cases we cannot use grub anymore. This feels as the same case of various other pieces of software that were no ready for users but were thrown onto them nevertheless. Can you say that NetworkManager works? Can you say that Fedora supports ipv6? Can you say that systemd was implemented at the right time? (still basic stuff as encrypted swap isn't handled correctly but was in the past) I'll stop here because you may get the idea.
110 lines of mostly os-prober. the rest of course will be blamed on grub2. but the same mantra holds true: no logging please! (unless something goes wrong)
Actually, os-prober does NOT provide any way to disable any kind of logging (well, except modifying the code!). If you want it, you can fill a bug upstream and probably provide a patch. Finally, it is not a place to discuss and solve all problems in the universe! You can discuss on fedora-devel about your opinions about Fedora and GNU/Linux in general! And AFAIK, os-prober doesn't have any configuration file and/or command line options, and it's main purpose is to be called by grub2-mkconfig. Probably this is why it doesn't have any man pages!
Why have a redhat fedora ugzilla if the quality improvements lie elsewhere? The 'upstream' mantra has been heard too often. You dive into the codex but not into the core of the message. You only confirm my opinion about the distro and the `processes` behind managing it.
If we look into the rpm somewhat more closely we see that os-prober is just a bunch of shell scripts. If we look into /usr/share/os-prober/common.sh we see a debug function which can easily be changed not to log to /var/log/messages. If the extra added quality of Redhat is limited to referring to upstream and not simply changing the script in a very minor way, let alone accepting this software into Fedora without actually looking at it (no check on logging, no check on manual page) then what can we expect from Fedora? This is very relevant so please do not reinvoke your mantra about problems of the universe. This is the very core of the problem of Redhat Fedora.
Well, the main question is: is turning of debug data a good (& obvious) choice? Apparently, its developers are not agree with you. I know that it can be disabled by modifying common.sh (and this is how I made sure that os-prober doesn't provide any way to disable it without changing the code). You say that disabling debug messages is a quality improvement, and you imply that it is obvious. So, why developers doesn't disable it? Fedora prefers to stick to upstream as much as possible, and have as little patches as possible. I prefer it too. Therefore, even if I would like to proceed further with your bug report, I'd report it upstream myself and wait for their reaction. I'm not sure if disabling debug messages (specially without providing any options to enable it) is a good choice. Distributions can try to improve the quality of the software they use, but their packages is NOT the best place to do it. It is better if they provide their quality improvement patches upstream, like a number of patches that I've sent to os-prober upstream already. However, you should provide your reasons for a change to developers, and in this case I think you are a better person to fill the bug upstream since you can better argue for this change. To sum it up: is disabling debug messages really a good choice?
The developer did not ask nor explain. There is not even documentation. The only (!) info is in the rpm description. The product should be used, not debugged. If we're just debugging instead of using, please say so. You do not release CentOS. If the developer is lazy or doesn't trust his own code he leaves in debugging. It may not be a conscious choice. I do not want debugging unless I am researching an issue. "is disabling debug messages really a good choice?" Yes. Especially if we can turn it on when the user wants it. It saves storage space and electricity not to mention annoyance. So in this case, where we cannot turn it on or off it is simply annoying as it serves no purpose. (stuff works, I see no problem except the logging)
I'd agree if user is able to enable or disable it easily, it can be turned off by default. Which is currently not the case. Specially, it should be enabled when being run by anaconda since the logs might be useful and anaconda itself saves its debug messages. Anyway, I still think that it is better to be handled upstream. You are exaggerating the problem, specially when it comes to storage space and electricity and even the annoyance. os-prober/grub2-mkconfig are rarely used by users. Actually, normally it is not executed by the end user at all. IMHO, diverging from upstream doesn't worth it in this situation. Regards
Some people do build their kernels. Users install stuff from repo's, I like my logs clean and just mentioning the essential stuff. In that perspective os-prober is a menace to my well-being and a clear sign of a lack of quality control. I already explained what is missing. Upstream is a mantra that is used way too much; in this case I got no response from the supposed author. Also 'upstream' degenerates the role that Redhat should play. This is just a script so why not alter it? Just get the upstream author at the keyboard to show that the person is till alive. Have them react to this bug and then we'll talk.
First, if you have reported the bug upstream (I felt that you might have) please add a reference to it above (under external trackers). But really, installing any packages from repos and even installing custom kernels should not call grub2-mkconfig. AFAIK, installing a new kernel will use grubby to add new entries, which edits grub.cfg directly. Packages also do, and should use grubby to modify grub configuration files. I wonder if there are any packages which execute grub2-mkconfig. Yes, modifying os-prober is easy. I prefer to not disable debugging messages as I don't feel comfortable with it. I brought an example, that generating debugging messages is at least needed when anaconda runs grub2-mkconfig. It can help debugging other installer components. Finally, yes I know that upstream is not much responsive. Among 4 patches I've sent upstream long ago, only one of them is considered and there are no responses for others. If I felt that fixing this issue is necessary, AND had a proper fix (which allows getting debug messages easily when needed), I would act on it. If you can have a proper fix, or at least you have an idea about fixing the issue while we can easily enable debugging messages (note that os-prober is almost always run by grub2-mkconfig, and not directly), let me know and I might create and apply the patch.