Since Fedora 18 will be the first release to lack an installer option to install GRUB to a partition, I think it's useful to mention this in release notes, and the recommended work arounds.
Draft text (but tested commands) included.
https://bugzilla.redhat.com/show_bug.cgi?id=872826#c36
Chris Murphy
Chris,
Thanks for the suggestion. Is there a ticket in Bugzilla for this yet?
On Sun, Dec 23, 2012 at 5:01 PM, Chris Murphy lists@colorremedies.com wrote:
Since Fedora 18 will be the first release to lack an installer option to install GRUB to a partition, I think it's useful to mention this in release notes, and the recommended work arounds.
Draft text (but tested commands) included.
https://bugzilla.redhat.com/show_bug.cgi?id=872826#c36
Chris Murphy
-- docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
On Sun, Dec 23, 2012 at 5:01 PM, Chris Murphy lists@colorremedies.com wrote:
Since Fedora 18 will be the first release to lack an installer option to install GRUB to a partition, I think it's useful to mention this in release notes, and the recommended work arounds.
Draft text (but tested commands) included.
On Dec 24, 2012, at 6:53 AM, Ben Cotton bcotton@fedoraproject.org wrote:
Chris,
Thanks for the suggestion. Is there a ticket in Bugzilla for this yet?
I don't understand the question.
Chris
Nevermind. I seem to have missed the link in your first message.
On Mon, Dec 24, 2012 at 1:58 PM, Chris Murphy lists@colorremedies.com wrote:
On Sun, Dec 23, 2012 at 5:01 PM, Chris Murphy lists@colorremedies.com wrote:
Since Fedora 18 will be the first release to lack an installer option to install GRUB to a partition, I think it's useful to mention this in release notes, and the recommended work arounds.
Draft text (but tested commands) included.
On Dec 24, 2012, at 6:53 AM, Ben Cotton bcotton@fedoraproject.org wrote:
Chris,
Thanks for the suggestion. Is there a ticket in Bugzilla for this yet?
I don't understand the question.
Chris
docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
On Dec 26, 2012, at 7:53 AM, Ben Cotton bcotton@fedoraproject.org wrote:
Nevermind. I seem to have missed the link in your first message.
There's feedback in the bug that points out there are user specific considerations that change the instructions, example given is boot on a separate partition.
I may be that a bulk of this belongs in the Installation Guide, and the release note just points out that installing GRUB to a partition is not supported, and where to get more information for recommended alternatives. I suspect release notes are to be more concise, rather than have full blown how-to guides in them.
e.g. If boot is on a separate partition, there's a change in prefix; if boot in on LVM, it's different yet again.
Also there's some concern about 'configfile' from a sufficiently old GRUB2 pre-release (which had been around for years before this summer's final release of 2.00), in which the early GRUB2 may not (fully) understand the present Fedora 18 GRUB2-2.00 based grub.cfg. There have been many syntax changes in grub.cfg which have at least affected grubby's ability to alter the grub.cfg, depending on the version of grub2-mkconfig that created it. So in this case, an entry in the first instance of GRUB2 using 'multiboot $prefix/i386-pc/core.img' can be used to load Fedora's GRUB.
Arguably users are hurting themselves by running such old pre-release versions of GRUB2, and in my opinion should be encouraged to upgrade GRUB from within their primary distro, or make Fedora their primary distro.
In comparison, the commands to create the core.img and grub.cfg are trivial to document than how to use them (per above). Nevertheless, I'm still hopeful that this NTH bug will take care of the creation part. https://bugzilla.redhat.com/show_bug.cgi?id=886502
Chris Murphy
On Dec 27, 2012 12:58 PM, "Chris Murphy" lists@colorremedies.com wrote:
On Dec 26, 2012, at 7:53 AM, Ben Cotton bcotton@fedoraproject.org wrote:
Nevermind. I seem to have missed the link in your first message.
There's feedback in the bug that points out there are user specific
considerations that change the instructions, example given is boot on a separate partition.
I may be that a bulk of this belongs in the Installation Guide, and the
release note just points out that installing GRUB to a partition is not supported, and where to get more information for recommended alternatives. I suspect release notes are to be more concise, rather than have full blown how-to guides in them.
e.g. If boot is on a separate partition, there's a change in prefix; if
boot in on LVM, it's different yet again.
Also there's some concern about 'configfile' from a sufficiently old
GRUB2 pre-release (which had been around for years before this summer's final release of 2.00), in which the early GRUB2 may not (fully) understand the present Fedora 18 GRUB2-2.00 based grub.cfg. There have been many syntax changes in grub.cfg which have at least affected grubby's ability to alter the grub.cfg, depending on the version of grub2-mkconfig that created it. So in this case, an entry in the first instance of GRUB2 using 'multiboot $prefix/i386-pc/core.img' can be used to load Fedora's GRUB.
Arguably users are hurting themselves by running such old pre-release
versions of GRUB2, and in my opinion should be encouraged to upgrade GRUB from within their primary distro, or make Fedora their primary distro.
In comparison, the commands to create the core.img and grub.cfg are
trivial to document than how to use them (per above). Nevertheless, I'm still hopeful that this NTH bug will take care of the creation part.
https://bugzilla.redhat.com/show_bug.cgi?id=886502
Chris Murphy
--
I've been pondering this topic , and other conversations from various lists on the state of anaconda. A lot of work has gone into the Installation Guide for this release, and I agree that it is probably the best place for more specific details.
For the Release Notes, I'm hesitant to delve into the various affected use cases; a blurb might be insufficient, a couple paragraphs too much, and including some situations alludes to the omission of others. How do we all feel about a note along the lines of "Not all features are available from the GUI, but advanced needs can be met with a kickstart installation or through post-install configuration" with links to appropriate documentation?
The concern about should certainly be in the 'common bugs' wiki page, if not the release notes. I'll watch the bug.
On Thu, 2012-12-27 at 14:10 -0700, Pete Travis wrote:
I've been pondering this topic , and other conversations from various lists on the state of anaconda. A lot of work has gone into the Installation Guide for this release, and I agree that it is probably the best place for more specific details.
For the Release Notes, I'm hesitant to delve into the various affected use cases; a blurb might be insufficient, a couple paragraphs too much, and including some situations alludes to the omission of others. How do we all feel about a note along the lines of "Not all features are available from the GUI, but advanced needs can be met with a kickstart installation or through post-install configuration" with links to appropriate documentation?
The concern about should certainly be in the 'common bugs' wiki page, if not the release notes. I'll watch the bug.
It has already been added to the install guide in response to my mail of Nov 30th. It is not appropriate for common bugs as it is not a bug.
On Sun, 2012-12-23 at 15:01 -0700, Chris Murphy wrote:
Since Fedora 18 will be the first release to lack an installer option to install GRUB to a partition, I think it's useful to mention this in release notes, and the recommended work arounds.
Draft text (but tested commands) included.
See thread "install guide notes: bootloader" from this list, dated Nov 30th.
On Jan 3, 2013, at 1:53 AM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2012-12-23 at 15:01 -0700, Chris Murphy wrote:
Since Fedora 18 will be the first release to lack an installer option to install GRUB to a partition, I think it's useful to mention this in release notes, and the recommended work arounds.
Draft text (but tested commands) included.
See thread "install guide notes: bootloader" from this list, dated Nov 30th.
I saw and replied to that thread a while ago; it contains no work arounds or alternatives to what will be the Fedora 18 boot loader options: all or none, also known as wipe out existing boot loader, or have an unbootable system.
I have no doubt this will be seen as a major regression (one I agree with, but I think how people should connect the dots ought to be documented). I think work arounds should be documented, other than telling people to use kickstart.
Chris Murphy
I saw and replied to that thread a while ago; it contains no work arounds
or alternatives to what will be the Fedora 18 boot loader options: all or none, also known as wipe out existing boot loader, or have an unbootable system.
I have no doubt this will be seen as a major regression (one I agree
with, but I think how people should connect the dots ought to be documented). I think work arounds should be documented, other than telling people to use kickstart.
Chris Murphy
Okay, I'm game for improvement. We can put in a dedicated note to establish grub expectations.
There's a list of things anaconda can't or won't do that might be fitting in the release notes. I've been deliberately vague in this beat on such things because I want readers to get a positive impression of newUI and a bunch of negatives makes that harder. Not impossible, though; I like the new anaconda.
On Jan 3, 2013, at 5:52 PM, Pete Travis me@petetravis.com wrote:
I saw and replied to that thread a while ago; it contains no work arounds or alternatives to what will be the Fedora 18 boot loader options: all or none, also known as wipe out existing boot loader, or have an unbootable system.
I have no doubt this will be seen as a major regression (one I agree with, but I think how people should connect the dots ought to be documented). I think work arounds should be documented, other than telling people to use kickstart.
Chris Murphy
Okay, I'm game for improvement. We can put in a dedicated note to establish grub expectations.
There's a list of things anaconda can't or won't do that might be fitting in the release notes. I've been deliberately vague in this beat on such things because I want readers to get a positive impression of newUI and a bunch of negatives makes that harder. Not impossible, though; I like the new anaconda.
I wouldn't so much characterize it as a negative, as much as it's in conforming with upstream recommendations (or maybe upstream best practices).
Interestingly, kickstart-configurator appears to have the oldui install boot loader to a partition option. I don't know if that means it's "supported"; and also if it makes sense to punt and document merely the --force flag to use block lists like kickstart and prior anacondas? It's certainly easier to document, although with a retort from GRUB2 that block lists aren't recommended.
And then perhaps change this for F19, by going with documenting the more stable and recommended approaches (using configfile, multiboot, or kernel).
Chris Murphy
On Jan 3, 2013 7:07 PM, "Chris Murphy" lists@colorremedies.com wrote:
On Jan 3, 2013, at 5:52 PM, Pete Travis me@petetravis.com wrote:
I saw and replied to that thread a while ago; it contains no work
arounds or alternatives to what will be the Fedora 18 boot loader options: all or none, also known as wipe out existing boot loader, or have an unbootable system.
I have no doubt this will be seen as a major regression (one I agree
with, but I think how people should connect the dots ought to be documented). I think work arounds should be documented, other than telling people to use kickstart.
Chris Murphy
Okay, I'm game for improvement. We can put in a dedicated note to
establish grub expectations.
There's a list of things anaconda can't or won't do that might be
fitting in the release notes. I've been deliberately vague in this beat on such things because I want readers to get a positive impression of newUI and a bunch of negatives makes that harder. Not impossible, though; I like the new anaconda.
I wouldn't so much characterize it as a negative, as much as it's in
conforming with upstream recommendations (or maybe upstream best practices).
Interestingly, kickstart-configurator appears to have the oldui install
boot loader to a partition option. I don't know if that means it's "supported"; and also if it makes sense to punt and document merely the --force flag to use block lists like kickstart and prior anacondas? It's certainly easier to document, although with a retort from GRUB2 that block lists aren't recommended.
And then perhaps change this for F19, by going with documenting the more
stable and recommended approaches (using configfile, multiboot, or kernel).
Chris Murphy
I don't mean negative in a technical sense, just in presentation. We can put a positive or negative spin on any change, or lack of it, it's just more work than simply stating the facts. If the reader is repeatedly told "No, you can't do that," they assume an undesirable connotation of the topic as a whole. I'll tackle that once I finish this seemingly endless trek home from the day job.
How do you feel about a cheerful direction to either put it on the MBR, or do it yourself? Would that be sufficient, given the level of detail in the Installation Guide?
On Jan 3, 2013, at 8:29 PM, Pete Travis me@petetravis.com wrote:
How do you feel about a cheerful direction to either put it on the MBR, or do it yourself? Would that be sufficient, given the level of detail in the Installation Guide?
I'm confused, the installation guide already does that. The red Warning at the bottom of this page: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Inst...
"If you choose not to install GRUB for any reason, you will not be able to boot the system directly, and you must use another boot method (such as a commercial boot loader application). Use this option only if you are sure you have another way of booting the system!"
I have no stake in this, I don't need to install GRUB to a partition. But based on testers, bug reporters, and users of previous versions of Fedora and other linux distros, a significant minority are used to being able to install GRUB to a partition. And this last line, "only if you are sure" in my opinion will lead to a negative reaction: "well what the hell, I definitely do NOT have another way of booting the system, and I don't want to nuke my current boot loader! Now what am I supposed to do?"
I'm suggesting giving them an explicit set of instructions for "do it yourself" rather than leave them hanging.
Chris Murphy
On Thu, Jan 3, 2013 at 8:59 PM, Chris Murphy lists@colorremedies.comwrote:
On Jan 3, 2013, at 8:29 PM, Pete Travis me@petetravis.com wrote:
How do you feel about a cheerful direction to either put it on the MBR,
or do it yourself? Would that be sufficient, given the level of detail in the Installation Guide?
I'm confused, the installation guide already does that. The red Warning at the bottom of this page:
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Inst...
"If you choose not to install GRUB for any reason, you will not be able to boot the system directly, and you must use another boot method (such as a commercial boot loader application). Use this option only if you are sure you have another way of booting the system!"
I have no stake in this, I don't need to install GRUB to a partition. But based on testers, bug reporters, and users of previous versions of Fedora and other linux distros, a significant minority are used to being able to install GRUB to a partition. And this last line, "only if you are sure" in my opinion will lead to a negative reaction: "well what the hell, I definitely do NOT have another way of booting the system, and I don't want to nuke my current boot loader! Now what am I supposed to do?"
I'm suggesting giving them an explicit set of instructions for "do it yourself" rather than leave them hanging.
Chris Murphy
I see your point, but I'm leaning towards explaining the reason for deprecation and the benefits of a unified grub configuration, with instructions on using grub2-mkconfig. The broader audience will get into less trouble that way.