Bug 699243 - plymouthd ignores all but first 512 bytes of kernel command line
Summary: plymouthd ignores all but first 512 bytes of kernel command line
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-24 15:10 UTC by Ian Pilcher
Modified: 2012-08-07 18:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-07 18:20:07 UTC
Type: ---


Attachments (Terms of Use)
boot.log with plymouth:debug (8.49 KB, text/plain)
2011-04-24 15:11 UTC, Ian Pilcher
no flags Details
dmesg with plymouth:debug (72.01 KB, text/plain)
2011-04-24 15:12 UTC, Ian Pilcher
no flags Details
/var/log/messages with plymouth:debug (74.38 KB, text/plain)
2011-04-24 15:23 UTC, Ian Pilcher
no flags Details
Patch to use a dynamically sized/allocated buffer for kernel command line (4.53 KB, patch)
2011-05-11 05:59 UTC, Ian Pilcher
no flags Details | Diff

Description Ian Pilcher 2011-04-24 15:10:21 UTC
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:

Comment 1 Ian Pilcher 2011-04-24 15:11:30 UTC
Created attachment 494531 [details]
boot.log with plymouth:debug

Comment 2 Ian Pilcher 2011-04-24 15:12:42 UTC
Created attachment 494532 [details]
dmesg with plymouth:debug

Comment 3 Ian Pilcher 2011-04-24 15:23:06 UTC
Created attachment 494534 [details]
/var/log/messages with plymouth:debug

Comment 4 Ray Strode [halfline] 2011-05-09 02:12:06 UTC
can you attach /var/log/plymouth-debug.log with plymouth.debug ?

Comment 5 Ian Pilcher 2011-05-09 11:41:41 UTC
(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.

Comment 6 James Laska 2011-05-09 14:17:20 UTC
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

Comment 7 Ian Pilcher 2011-05-09 19:42:14 UTC
(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?

Comment 8 Ian Pilcher 2011-05-10 01:48:17 UTC
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?

Comment 9 James Laska 2011-05-10 16:11:52 UTC
(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.

Comment 10 Ian Pilcher 2011-05-10 16:43:25 UTC
(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.

Comment 13 Ian Pilcher 2011-05-11 05:59:18 UTC
Created attachment 498205 [details]
Patch to use a dynamically sized/allocated buffer for kernel command line

Comment 14 Ray Strode [halfline] 2011-06-02 21:49:28 UTC
Hi Ian,

Thanks for the patch!

Any chance you could rework it to use ply_buffer_t , ply_buffer_append_bytes etc ?

Comment 15 Ray Strode [halfline] 2011-06-02 22:08:01 UTC
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)

Comment 16 Ian Pilcher 2011-06-04 01:42:35 UTC
(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.

Comment 17 Fedora End Of Life 2012-08-07 18:20:09 UTC
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


Note You need to log in before you can comment on or make changes to this bug.