Bug#789798: [RFR] New grub-installer-template
On Wed, 2015-07-01 at 07:00 +0200, Christian PERRIER wrote: _Description: Add GRUB to firmware NVRAM configuration? By default, GRUB will be registered into NVRAM on platforms where this is required, such as UEFI Boot Manager or OpenFirmware boot devices. . Occasionally this is not desired (for instance on systems that PXE boot and then chainload). If you do not choose this option, the NVRAM will be left untouched. Thanks, this is what I went with. I needed a similar text for grub2 itself, so I reused the same thing. I'll update the bug shortly. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
Christian PERRIER wrote: _Description: Add GRUB to firmware NVRAM configuration? By default, GRUB will be registered into NVRAM on platforms where this is required, such as UEFI Boot Manager or OpenFirmware boot devices. . Occasionally this is not desired (for instance on systems that PXE boot and then chainload). If you do not choose this option, the NVRAM will be left untouched. (eventually arrange the tenses as the above if likely to be Frenglish wrt to tenses) The tenses are fine (the only Frenglish you've got there is eventually), but if the default is still *do* add GRUB, that last sentence might still give a wrong impression of the results of inaction. Maybe we could say: Occasionally this is not desired (for instance on systems that PXE boot and then chainload). If you reject this option, the NVRAM will be left untouched. -- JBR less offline, more sunburnt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
Quoting Justin B Rye (justin.byam@gmail.com): (eventually arrange the tenses as the above if likely to be Frenglish wrt to tenses) The tenses are fine (the only Frenglish you've got there is eventually), but if the default is still *do* add GRUB, that Do, I know about eventually but I'm still doing that mistake too often. Well, that probably combines well with my bioutifoule akssente. Thanks again, Justin, for kindly correcting me...:-) (that one is probably en_FR again) last sentence might still give a wrong impression of the results of inaction. Maybe we could say: Occasionally this is not desired (for instance on systems that PXE boot and then chainload). If you reject this option, the NVRAM will be left untouched. Seems perfect to me signature.asc Description: Digital signature
Bug#789798: [RFR] New grub-installer-template
Hello l10n-english, In http://bugs.debian.org/789798 I've proposed a new debconf question for grub-installer (part of d-i which handles installing grub on those platforms which use it as a bootloader). The question is low priority and I would normally expect it to be used via preseeding, nonetheless some review of the wording would be appreciated. I've already applied the tweak suggested by Steve in the bug to the text below. Here it is: Template: grub-installer/no-nvram Type: boolean Default: false # :sl4: _Description: Avoid adding GRUB to Firmmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required. e.g. UEFI Boot Manager or OpenFirmware boot device. . This is sometimes not desirable, e.g. for systems which PXE boot and chainload instead and do not want the firmware configuration adjusted. Answering no here will avoid making such adjustments. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
Quoting Justin B Rye (justin.byam@gmail.com): _Description: Avoid adding GRUB to firmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required, such as UEFI Boot Manager or OpenFirmware boot devices. . Occasionally this is not desired (for instance on systems that PXE boot and then chainload). Answering yes here will leave NVRAM untouched. That's indeed forgetting that Thou Shalt Not Make Reference To Debconf Widgets. Indedd something like answering 'yes' is not something that should be used That should be along the lines of Choosing this option here will leave NVRAM untouched However, I'm not sure that this is the right choice. I'd prefer the question to be Add GRUB to firmware NVRAM configuration? _Description: Add GRUB to firmware NVRAM configuration? By default, GRUB will be registered into NVRAM on platforms where this is required, such as UEFI Boot Manager or OpenFirmware boot devices. . Occasionally this is not desired (for instance on systems that PXE boot and then chainload). If you do not choose this option, the NVRAM will be left untouched. (eventually arrange the tenses as the above if likely to be Frenglish wrt to tenses) signature.asc Description: Digital signature
Bug#789798: [RFR] New grub-installer-template
Ian Campbell i...@debian.org writes: Hello l10n-english, In http://bugs.debian.org/789798 I've proposed a new debconf question for grub-installer (part of d-i which handles installing grub on those platforms which use it as a bootloader). The question is low priority and I would normally expect it to be used via preseeding, nonetheless some review of the wording would be appreciated. I've already applied the tweak suggested by Steve in the bug to the text below. Here it is: Template: grub-installer/no-nvram Type: boolean Default: false # :sl4: _Description: Avoid adding GRUB to Firmmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required. e.g. UEFI Boot Manager or OpenFirmware boot device. . This is sometimes not desirable, e.g. for systems which PXE boot and chainload instead and do not want the firmware configuration adjusted. Answering no here will avoid making such adjustments. There seems to be a double negative here. The parameter is 'no-nvram' so I'd expect 'True' to indicate that one should avoid touching the NVRAM, whereas the text says: Answering _no_ here will avoid making such adjustments. I think that no should be yes. Also, the and do not want the firmware configuration adjusted. seems a bit redundant, given the preceding not desirable. How about: Ocasionally this is not desired (e.g. on systems that PXE boot and then chainload). Answering yes here will leave NVRAM untouched. BTW Is yes actually the right thing to say here? Or should one say setting the option or some such, so it works with GUIs that present this as a tick-box, say. I'd also make the device at the end of the first paragraph be devices instead. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#789798: [RFR] New grub-installer-template
Philip Hands wrote: Template: grub-installer/no-nvram Type: boolean Default: false # :sl4: _Description: Avoid adding GRUB to Firmmware NVRAM configuration? ^ Hang on, typo (and why capitalised?) By default GRUB will be registered into NVRAM on platforms where this is required. e.g. UEFI Boot Manager or OpenFirmware boot device. ^ Stop followed by lowercase e.g.? I'd suggest expanding the Latin abbreviation to such as here and for instance below. Then taking your revisions: Ocasionally this is not desired (e.g. on systems that PXE boot and then ^ Typo: occasionally. PXE boot as a verb might want a hyphen, but then again maybe not. chainload). Answering yes here will leave NVRAM untouched. Or setting this option, or maybe accepting, though that might be confusing with Default: false and yes meaning avoid doing it... I'll leave it for now. So: _Description: Avoid adding GRUB to firmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required, such as UEFI Boot Manager or OpenFirmware boot devices. . Occasionally this is not desired (for instance on systems that PXE boot and then chainload). Answering yes here will leave NVRAM untouched. -- JBR slightly offline, slightly sunburnt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789798: [RFR] New grub-installer-template
On Tue, 2015-06-30 at 10:28 +0100, Philip Hands wrote: Ian Campbell i...@debian.org writes: Hello l10n-english, In http://bugs.debian.org/789798 I've proposed a new debconf question for grub-installer (part of d-i which handles installing grub on those platforms which use it as a bootloader). The question is low priority and I would normally expect it to be used via preseeding, nonetheless some review of the wording would be appreciated. I've already applied the tweak suggested by Steve in the bug to the text below. Here it is: Template: grub-installer/no-nvram Type: boolean Default: false # :sl4: _Description: Avoid adding GRUB to Firmmware NVRAM configuration? By default GRUB will be registered into NVRAM on platforms where this is required. e.g. UEFI Boot Manager or OpenFirmware boot device. . This is sometimes not desirable, e.g. for systems which PXE boot and chainload instead and do not want the firmware configuration adjusted. Answering no here will avoid making such adjustments. There seems to be a double negative here. The parameter is 'no-nvram' so I'd expect 'True' to indicate that one should avoid touching the NVRAM, whereas the text says: Answering _no_ here will avoid making such adjustments. I think that no should be yes. Indeed, checking the code: +# Should we avoid installing/registering GRUB in NVRAM? + db_input low grub-installer/no-nvram || [ $? -eq 30 ] + db_go || exit 10 + db_get grub-installer/no-nvram + if [ $RET = true ]; then + grub_install_params=$grub_install_params --no-nvram + # Make sure this happens on upgrades too + $chroot $ROOT 'debconf-set-selections' EOF +grub-installer/no-nvram boolean true +EOF + fi I did seem to mean yes. Also, the and do not want the firmware configuration adjusted. seems a bit redundant, given the preceding not desirable. How about: Ocasionally this is not desired (e.g. on systems that PXE boot and then chainload). Answering yes here will leave NVRAM untouched. Sounds good. BTW Is yes actually the right thing to say here? Or should one say setting the option or some such, so it works with GUIs that present this as a tick-box, say. I'll assume this is a question to the list since I have no idea... (it does sound sensible though). I'd also make the device at the end of the first paragraph be devices instead. Sure. Thanks for the review! Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
