* read the dracut man page * remove "rhgb" from the kernel command line and maybe "quiet" * add "rdshell" to the kernel command line and you are dropped to a shell * add "rdshell rdinitdebug" to the kernel command line and dracut shell commands are printed as they are executed * with dracut >= 002-11 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less
Am 01.10.2009 21:35, schrieb Harald Hoyer:
- read the dracut man page
- remove "rhgb" from the kernel command line and maybe "quiet"
- add "rdshell" to the kernel command line and you are dropped to a shell
- add "rdshell rdinitdebug" to the kernel command line and dracut shell
commands are printed as they are executed
- with dracut >= 002-11 (
http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less
oh, and you might be able to
* mount /boot or * ifup eth0 and nfs mount a share
to copy over /init.log or the whole dmesg output
On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote:
- read the dracut man page
- remove "rhgb" from the kernel command line and maybe "quiet"
- add "rdshell" to the kernel command line and you are dropped to a shell
- add "rdshell rdinitdebug" to the kernel command line and dracut shell commands
are printed as they are executed
- with dracut >= 002-11 (
http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less
It could probably use some more polish, but I've added your comments to https://fedoraproject.org/wiki/How_to_debug_Dracut_problems
Thanks, James
On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote:
- read the dracut man page
- remove "rhgb" from the kernel command line and maybe "quiet"
- add "rdshell" to the kernel command line and you are dropped to a shell
- add "rdshell rdinitdebug" to the kernel command line and dracut shell commands
are printed as they are executed
- with dracut >= 002-11 (
http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less
Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks.
On 10/01/2009 08:02 PM, Adam Williamson wrote:
On Thu, 2009-10-01 at 21:35 +0200, Harald Hoyer wrote:
- read the dracut man page
- remove "rhgb" from the kernel command line and maybe "quiet"
- add "rdshell" to the kernel command line and you are dropped to a shell
- add "rdshell rdinitdebug" to the kernel command line and dracut shell commands
are printed as they are executed
- with dracut>= 002-11 (
http://koji.fedoraproject.org/koji/buildinfo?buildID=134721 ), you can inspect the rdinitdebug output with: # less /init.log and # dmesg | less
Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks.
Is this the new format/path of debugging pages for a given component how_to_debug_<component>_problem as opposed to https://fedoraproject.org/wiki/Dracut/Debugging or <component>/Debugging> and are we going to move all debugging pages under how_to_debug??
Who ever changed the original one should take the time and update https://fedoraproject.org/wiki/Dracut/Options to current options listen in git logs or atleast the man page and remove all <pre> and {{admon}} to make it consistent with the new debugging page..
JBG
On Thu, 2009-10-01 at 22:09 +0000, "Jóhann B. Guðmundsson" wrote:
Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks.
Is this the new format/path of debugging pages for a given component how_to_debug_<component>_problem as opposed to https://fedoraproject.org/wiki/Dracut/Debugging or <component>/Debugging> and are we going to move all debugging pages under how_to_debug??
It hasn't been officially discussed anywhere - I was using Bug_info_componentname myself - but I think it's a good choice by whoever came up with it. It also fits in with the request of the Wiki admin team that we use flat page names, not nested ones.
Who ever changed the original one should take the time and update https://fedoraproject.org/wiki/Dracut/Options to current options listen in git logs or atleast the man page and remove all <pre> and {{admon}} to make it consistent with the new debugging page..
On 10/01/2009 10:26 PM, Adam Williamson wrote:
On Thu, 2009-10-01 at 22:09 +0000, "Jóhann B. Guðmundsson" wrote:
Please also see https://fedoraproject.org/wiki/How_to_debug_Dracut_problems , the permanent reference for this topic. I'll add anything in Harald's mail that's not currently on that page to it. Thanks.
Is this the new format/path of debugging pages for a given component how_to_debug_<component>_problem as opposed to https://fedoraproject.org/wiki/Dracut/Debugging or <component>/Debugging> and are we going to move all debugging pages under how_to_debug??
It hasn't been officially discussed anywhere - I was using Bug_info_componentname myself - but I think it's a good choice by whoever came up with it. It also fits in with the request of the Wiki admin team that we use flat page names, not nested ones.
Well I think the documentation team ( doc list cc-ed ) should provide us with rules and regulation ( or templates ) on how component page should be written including bug reporting etc.. and who the target audience is so at-least some consistency exist in the wiki, I personally write pages targeted at novice end user so they tend to be more step by step oriented since I believe that we should expose testing of a component to as wide audience as possible regardless of the individual skill ( it might be a kid taking his first step into the linux, Fedora community and participate or it might be an experienced user ) set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community. When an indvidual changes the layout of my wiki written pages ( other than simply fix my ken-lee English ) I believe ( since he thinks he does a better job than me delivering the content of the page to well what he sees as the target audience ) that he will maintain the given component pages and keep it update to upstream documentation. ( since he has the time to totally rewrite the page he should have the time to do the necessary research and keep it updated to upstream documentation/changes/git logs ). It's not enough simply write those pages they need to be maintained and updated as well and I for one don't participate in wiki writing ping pong game..
JBG
On Thu, 2009-10-01 at 23:39 +0000, "Jóhann B. Guðmundsson" wrote:
set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community
I think you're setting up a straw man here. I haven't seen anyone on this list suggest any such thing, and I don't see that any of the existing pages are intentionally written in this way. It would be good to have consistent styles for such pages, but there's no need to set it up in such a confrontational way.
On 10/01/2009 11:53 PM, Adam Williamson wrote:
On Thu, 2009-10-01 at 23:39 +0000, "Jóhann B. Guðmundsson" wrote:
set while other voices in the community think that they should have University, RHCE or some other degree stuck up their ass to be able to participate in testing or other aspects of the community
I think you're setting up a straw man here. I haven't seen anyone on this list suggest any such thing, and I don't see that any of the existing pages are intentionally written in this way. It would be good to have consistent styles for such pages, but there's no need to set it up in such a confrontational way.
As I said "other voices" I never said they resided on this list ( I dont keep tap who's on this list or any other list for that matter ) however you should recall atleast one such debate when we rewrote/redesigned the QA frontpage on the wiki.. I feel we definitively needs some wiki rules and regulations. When I started to write wiki pages I was pointed out that I should write those pages on my name space followed by pointing other members of the community to that page and if the community was happy with the content/layout it would be move to the front if not I should A) rewrite the page according to suggestion and resubmit or B) those that did not agree with the content layout of that page should draft what ever they think it should look like and submit that. if I would change an already published wiki page I should comment in the page it self why I made those changes . Now I had barely finished wikifying for example Sysrq ( Now https://fedoraproject.org/wiki/QA/Sysrq ) and was waiting for feed back from the community ( for example if it was simple/clear enough ) when it got yanked out of my personal space and dump where it resides now ( which probably not where the wiki admins want it to reside ). Either we create pages at will submit them when accepted they get move to the front then if a rewriting ( other than minor changes such as typo fixing etc ) occurs the individual that wants to rewrite the current page does so on his own name space and submits his changes or everybody hack everything everywhere on the wiki and constantly play wiki rewriting ping pong game of how their perception on how things should look/be written. One half says user your own namespace and submit your suggestion comment when changing.the other halfs says wanna change something on the wiki change it. I think the community needs to agree on which way it should be.
JBG
PS. Good coders make crappy documents. If and when they find the time to write them they usually tend to be to technical/development oriented even tho the indented audience is the end user.
On Fri, 2009-10-02 at 01:35 +0000, "Jóhann B. Guðmundsson" wrote:
As I said "other voices" I never said they resided on this list ( I dont keep tap who's on this list or any other list for that matter ) however you should recall atleast one such debate when we rewrote/redesigned the QA frontpage on the wiki.. I feel we definitively needs some wiki rules
It would help if you'd split things into paragraphs, my eyes keep glazing over after four lines...
and regulations. When I started to write wiki pages I was pointed out that I should write those pages on my name space followed by pointing other members of the community to that page and if the community was happy with the content/layout it would be move to the front if not I should A) rewrite the page according to suggestion and resubmit or B) those that did not agree with the content layout of that page should draft what ever they think it should look like and submit that.
That's the procedure we follow for particularly significant and important pages - like the most popular few pages for a group (the Bugzappers front page, joining page etc). It doesn't scale to _every page in the Wiki_, there just aren't the resources to review everything. For a less significant page like this, it doesn't need review.
if I would change an already published wiki page I should comment in the page it self why I made those changes .
That's not correct, you should explain in the comment box when you make the change. If you need a longer justification than that space allows, put it on the Talk page.
Now I had barely finished wikifying for example Sysrq ( Now https://fedoraproject.org/wiki/QA/Sysrq ) and was waiting for feed back from the community ( for example if it was simple/clear enough ) when it got yanked out of my personal space and dump where it resides now ( which probably not where the wiki admins want it to reside ).
That sounds strange, I didn't know anything about it happening at the time. Who moved it? What was the rationale?
Having said that, that's probably an example of a page it's fine to just create directly - it's not crucial enough to require drafting and formal review, though of course it's always good to get other people's opinions on the page if you can :)
Either we create pages at will submit them when accepted they get move to the front then if a rewriting ( other than minor changes such as typo fixing etc ) occurs the individual that wants to rewrite the current page does so on his own name space and submits his changes or everybody hack everything everywhere on the wiki and constantly play wiki rewriting ping pong game of how their perception on how things should look/be written.
In practice, it's usually easy to compromise. Since everyone's basically pointing in the same direction here, and it's easy to collaborate, that kind of ping-ponging doesn't happen too often. When it does get started, we can agree to bring both perspectives to a meeting or ML discussion and decide on the best approach with the approval of the rest of the group.
One half says user your own namespace and submit your suggestion comment when changing.the other halfs says wanna change something on the wiki change it. I think the community needs to agree on which way it should be.
As I said, I don't think this is an area where there needs to be One True Way. Different groups and different pages can take different approaches. As long as the information gets out there in the end, it's okay.
-
"Jóhann B. Guðmundsson" -
Adam Williamson -
Harald Hoyer -
James Laska