Bug 699243
| Summary: | plymouthd ignores all but first 512 bytes of kernel command line | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ian Pilcher <ipilcher> | ||||||||||
| Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 15 | CC: | fedora, jlaska, rstrode | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-08-07 18:20:07 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: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 494531 [details]
boot.log with plymouth:debug
Created attachment 494532 [details]
dmesg with plymouth:debug
Created attachment 494534 [details]
/var/log/messages with plymouth:debug
can you attach /var/log/plymouth-debug.log with plymouth.debug ? (In reply to comment #4) > can you attach /var/log/plymouth-debug.log with plymouth.debug ? I've tried booting with both "plymouth:debug" and "plymouth.debug". Neither one produces that file. Any change in behavior using more recent packages? Note, you may be required to rebuild your initrd (using `dracut`) depending on the order in which you've installed the updates. kernel-2.6.38.5-24.fc15.x86_64 plymouth-0.8.4-0.20110427.1.fc15.x86_64 (In reply to comment #6) > Any change in behavior using more recent packages? Note, you may be required > to rebuild your initrd (using `dracut`) depending on the order in which you've > installed the updates. > > kernel-2.6.38.5-24.fc15.x86_64 > plymouth-0.8.4-0.20110427.1.fc15.x86_64 No change. I just did a "yum update", which pulled in that kernel, and then ran "plymouth-set-default-theme charge --rebuild-initrd" for good measure. (plymouth was already at the latest version.) Still no graphical boot and no log. BTW, is it supposed to be "plymouth:debug" or "plymouth.debug" on the kernel command line? The root cause of the failure to start the graphical boot, as well as the failure to produce a debug log, is that plymouthd only bothers to look at the first 512 bytes of the kernel command line. I have updated the bug summary to this effect. (So my problem wasn't the Sandy Bridge graphics, it was using the anaconda- generated kernel command line on a system with a bunch of MD RAID devices.) I think it's only reasonable that the person who coded this be staked out over a fire ant hill for some period of time -- say 512 minutes? Would that be considered an RFE? (In reply to comment #8) > The root cause of the failure to start the graphical boot, as well as the > failure to produce a debug log, is that plymouthd only bothers to look at > the first 512 bytes of the kernel command line. I have updated the bug > summary to this effect. > > (So my problem wasn't the Sandy Bridge graphics, it was using the anaconda- > generated kernel command line on a system with a bunch of MD RAID devices.) Can you provide evidence or data (e.g. boot logs using different cmdline args) to support your conclusion? > I think it's only reasonable that the person who coded this be staked out > over a fire ant hill for some period of time -- say 512 minutes? Would that > be considered an RFE? I appreciate your testing, however you know that those comments are not helpful and do not move this issue forward. (In reply to comment #9) > Can you provide evidence or data (e.g. boot logs using different cmdline args) > to support your conclusion? Take a look at main.c, specifically the line that reads ... #define PLY_MAX_COMMAND_LINE_SIZE 512 ... and what that constant is used for. I've also verified that moving the "rhgb" parameter earlier in the kernel command line get me the graphical boot. Created attachment 498205 [details]
Patch to use a dynamically sized/allocated buffer for kernel command line
Hi Ian, Thanks for the patch! Any chance you could rework it to use ply_buffer_t , ply_buffer_append_bytes etc ? we should probably also limit it to reasonable size since if /proc/cmdline is 2 megabytes long or something then trusting it would be wrong I think. We could use a 4096 (I remember reading somewhere that /proc entries can only be a page long anyway, but that limitation is outdated now i think) We could also use COMMAND_LINE_SIZE from kernel headers, but that's 512...(and is the original motivation for me picking 512) (In reply to comment #14) > Any chance you could rework it to use ply_buffer_t , ply_buffer_append_bytes > etc ? I will give that a shot. Not sure when I will be able to get to it, however, ... (In reply to comment #15) > we should probably also limit it to reasonable size since if /proc/cmdline is 2 > megabytes long or something then trusting it would be wrong I think. > > We could use a 4096 (I remember reading somewhere that /proc entries can only > be a page long anyway, but that limitation is outdated now i think) > > We could also use COMMAND_LINE_SIZE from kernel headers, but that's 512...(and > is the original motivation for me picking 512) I went looking for kernel command line limit when I first realized what was happening. Unfortunately, I found out that there really isn't one any more. (Although I suppose grub probably imposes a limit.) My patch actually does limit it to PLY_READ_BUF_CHUNK * PLY_MAX_READ_BUF_CHUNKS bytes, which is 64K. This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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" (top right of this page) 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 |
Description of problem: When starting Fedora 15 on a system with an Intel Core i7 2600 "Sandy Bridge" processor, using the integrated "HD 2000" GPU, kernel modesetting works just fine, but I do not get the plymouth graphical boot. Version-Release number of selected component (if applicable): kernel-2.6.38.3-18.fc15.x86_64 plymouth-0.8.4-0.20110304.1.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1. sudo plymouth-set-default-theme charge --rebuild-initrd 2. Edit /etc/grub.conf and ensure that the kernel command line includes "quiet rhgb" 3. Reboot Actual results: Kernel modesetting works, but the graphical boot is not displayed, just text. Expected results: Graphical boot ("charge" in this case) should be displayed. Additional info: