Re: [Bug 752059] MajorMod: Manually Upgrading the Kernel: Update for GRUB 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hash: SHA1


On 04/24/2012 04:05 PM, Chris Murphy wrote:
> The software is not outdated. The F16 documentation was outdated
> immediately upon being published, i.e. it's always been incorrect
> for F16. That's what the subject's bug ID is about.
> GRUB 2 shipped in F16, but the F16 System Admin Guide references
> GRUB Legacy. So it's a useless entry at best. And confusing at
> worst (although there's a chance someone could make their system
> unbootable by following the existing documentation).
> So there is no in-line editing of the exiting documentation
> possible? Because there are some things I'd keep, like the sidebars
> on initrd/initramfs.
> Chris Murphy

I don't know this for sure, but I somehow remember that we aren't
supposed to update published Guides unless there's a danger of
somebody damaging their system. As you note, in this case there is.


> On Apr 24, 2012, at 1:44 PM, Christopher R. Antila wrote:
> Hi:
> When drafting documentation on the wiki, you could just make a new 
> page in your namespace. Like this:
> Also, I'm not sure that "outdated software" is a reason we update 
> already-published documentation. jhradile is the maintainer listed
> on the guides table[0], so it's their responsibility to decide when
> to publish.
> Thanks for contributing!
> Christopher
> [0]
> On 04/24/2012 11:44 AM, Chris Murphy wrote:
>>>> This edit ideally should be applied to both F16 and F17. It
>>>> does not apply to F15.
>>>> On Apr 24, 2012, at 9:41 AM, Chris Murphy wrote:
>>>>> Hi Christopher,
>>>>> I should have a draft in the next day or two, that I can
>>>>> then incorporate into the wiki. Although I'm not exactly
>>>>> sure how to do that.
>>>>> I have a FAS account and CLA signed. I have read: 
>>>>> Since there's an open bug on this issue, I went to: 
>>>>> I'm not finding a page on how to do revisions within the
>>>>> wiki on this particular bug.
>>>>> Thanks,
>>>>> Chris Murphy
>>>>> On Apr 23, 2012, at 8:19 PM, Christopher R. Antila wrote:
>>>> Hi Chris:
>>>> If this is, as it seems to be, an offer to help out by
>>>> replacing outdated documentation, then yes please! The
>>>> easiest way is probably to write and revise it on the wiki,
>>>> then post a URL as a comment on the bug.
>>>> But first... maybe wait a day or two to see if anybody else
>>>> is already working on it. I just checked the latest version
>>>> in git, and the relevant section appears to be unchanged, but
>>>> the System Administrator's Guide is frequently updated, so
>>>> you never know.
>>>> Welcome to fedora-docs!
>>>> Christopher.
>>>> On 04/23/2012 01:25 AM, Chris Murphy wrote:
>>>>>>>> Hi,
>>>>>>>> First post to this list. I've offered various
>>>>>>>> observations on devel@ and Fedora Forums on: general
>>>>>>>> boot behavior, with emphasis on making dual and
>>>>>>>> triple booting work on Macs; issues surrounding MBR
>>>>>>>> and GPT partitioning schemes; and the lunatic asylum
>>>>>>>> of (U)EFI, CSM-BIOS and BIOS mode booting of
>>>>>>>> hardware.
>>>>>>>> I see the bug is assigned, but no activity since Nov
>>>>>>>> 2011. If agreeable, I can take on an edit for F16
>>>>>>>> which would also carry over to F17. The fix is very
>>>>>>>> straightforward. As described in the bug, primarily
>>>>>>>> it's removal of the bulk of existing text, because
>>>>>>>> the current text is almost entirely obsoleted by
>>>>>>>> GRUB2. And then documenting the proper command for
>>>>>>>> the included GRUB2 script that causes the
>>>>>>>> regeneration of a new grub.cfg. I'd expect the
>>>>>>>> section to be cut in size and complexity by 80%,
>>>>>>>> accounting for a mention of perhaps three optional
>>>>>>>> custom configurations that admins may find useful.
>>>>>>>> And probably also include some note to the effect 
>>>>>>>> that direct editing of the grub.cfg is not
>>>>>>>> recommended by upstream, therefore advanced users who
>>>>>>>> do edit the file are advised grub.cfg can be
>>>>>>>> overwritten without notice, and are better off making
>>>>>>>> their custom inclusions in the proper /etc/grub.d
>>>>>>>> files, and then executing the regeneration script.
>>>>>>>> Basically, start simple and general purpose, and then
>>>>>>>> get to a few specific examples. And leave the rest to
>>>>>>>> upstream documentation.
>>>>>>>> A bit more complicated right now is bug 750108. It
>>>>>>>> might be best to remove the current material, and
>>>>>>>> reference Anaconda's option to configure this at
>>>>>>>> install time as the absolute easiest way to deal with
>>>>>>>> it. And reference upstream's documentation until
>>>>>>>> someone gets around to writing a reasonable step by
>>>>>>>> step for doing it post-install. Better than than
>>>>>>>> obsolete material that won't work.
>>>>>>>> Chris Murphy
>>>>>> -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To 
>>>>>> unsubscribe: 
>>>>> -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To 
>>>>> unsubscribe: 
>> -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To
>> unsubscribe: 
Version: GnuPG v1.4.12 (GNU/Linux)

docs mailing list
To unsubscribe:

[Home]     [Fedora Legacy]     [Fedora Desktop]     [Red Hat 9 Bible]     [Fedora Bible]     [Red Hat 9]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

Powered by Linux