[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
** Changed in: curtin Status: Confirmed => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Invalid Status in MAAS: Fix Released Status in MAAS 2.2 series: Won't Fix Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Fix Released Status in grub2-signed source package in Trusty: Fix Released Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Yakkety: Won't Fix Status in grub2-signed source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
This bug was fixed in the package grub2 - 2.02~beta2-9ubuntu1.16 --- grub2 (2.02~beta2-9ubuntu1.16) trusty; urgency=medium [ Ivan Hu ] * debian/patches/0001-i386-linux-Add-support-for-ext_lfb_base.patch: Add support for ext_lfb_base. (LP: #1785033) [ dann frazier ] * Add grub2/update_nvram template to allow users to disable NVRAM updates during package upgrades (LP: #1642298). [ Mathieu Trudel-Lapierre ] * debian/patches: Rework linuxefi/SecureBoot support and sync with upstream SB patch set: (LP: #1696599) - linuxefi_backport_arm64.patch: backport basic arm64 chainload/linux command support from 17.04. - linuxefi_arm_sb_support.patch: add Secure Boot support for arm for its chainloader. - linuxefi_fix_validation_race.patch: Fix a race in validating images. - linuxefi_chainloader_path.patch: honor the starting path for grub, so images do not need to be started from $root. - linuxefi_chainloader_sb.patch: Fix some more issues in chainloader use when Secure Boot is enabled. - linuxefi_loaders_enforce_sb.patch: Enforce Secure Boot policy for all loaders: don't load the commands when Secure Boot is enabled. - linuxefi_re-enable_linux_cmd.patch: Since we rely on the linux and initrd commands to automatically hand-off to linuxefi/initrdefi; re- enable the linux loader. - linuxefi_chainloader_pe_fixes.patch: PE parsing fixes for chainloading "special" PE images, such as Windows'. - linuxefi_rework_non-sb_cases.patch: rework cases where Secure Boot is disabled or shim validation is disabled so loading works as EFI binaries when it is supposed to. - Removed linuxefi_require_shim.patch; superseded by the above. - Removed linuxefi_amd64_only.patch; superseded by the above. - Refreshed patches. * debian/rules: disable the use of -Werror while building grub; the EFI patches have subtle cases which trip it up unnecessarily. * debian/patches/arm64-set-correct-length-of-device-path-end-entry.patch: dropped; included in linuxefi_backport_arm64.patch. * debian/patches/linuxefi_fix_relocate_coff.patch: fix typo in relocate_coff() causing issues with relocation of code in chainload. (LP: #1792575) * debian/patches/linuxefi_truncate_overlong_relocs.patch: The Windows 7 bootloader has inconsistent headers; truncate to the smaller, correct size to fix chainloading Windows 7. (LP: #1792575) -- Mathieu Trudel-Lapierre Tue, 08 Jan 2019 12:36:49 -0500 ** Changed in: grub2 (Ubuntu Trusty) Status: Fix Committed => Fix Released ** Changed in: grub2-signed (Ubuntu Trusty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: Fix Released Status in MAAS 2.2 series: Won't Fix Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Fix Released Status in grub2-signed source package in Trusty: Fix Released Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Yakkety: Won't Fix Status in grub2-signed source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. -
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
** Changed in: maas/2.2 Status: Triaged => Won't Fix ** Changed in: maas/2.2 Milestone: 2.2.3 => None -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: Fix Released Status in MAAS 2.2 series: Won't Fix Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Triaged Status in grub2-signed source package in Trusty: New Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Yakkety: Won't Fix Status in grub2-signed source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
This bug was fixed in the package grub2-signed - 1.66.14 --- grub2-signed (1.66.14) xenial; urgency=medium * Rebuild against grub2 2.02~beta2-36ubuntu3.14. (LP: #1642298) -- dann frazier Mon, 25 Sep 2017 09:36:55 -0600 ** Changed in: grub2-signed (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: Fix Released Status in MAAS 2.2 series: Triaged Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Triaged Status in grub2-signed source package in Trusty: New Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Yakkety: Won't Fix Status in grub2-signed source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.14 --- grub2 (2.02~beta2-36ubuntu3.14) xenial; urgency=medium * Add grub2/update_nvram template to allow users to disable NVRAM updates during package upgrades (LP: #1642298). -- dann frazier Thu, 14 Sep 2017 16:13:39 -0600 ** Changed in: grub2 (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: Fix Released Status in MAAS 2.2 series: Triaged Status in grub2 package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Triaged Status in grub2-signed source package in Trusty: New Status in grub2 source package in Xenial: Fix Released Status in grub2-signed source package in Xenial: Fix Released Status in grub2 source package in Yakkety: Won't Fix Status in grub2-signed source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
** Changed in: maas Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: Fix Released Status in MAAS 2.2 series: Triaged Status in grub2 package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Triaged Status in grub2 source package in Xenial: Triaged Status in grub2 source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
** Changed in: grub2 (Ubuntu Yakkety) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: Fix Committed Status in MAAS 2.2 series: Triaged Status in grub2 package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Triaged Status in grub2 source package in Xenial: Triaged Status in grub2 source package in Yakkety: Won't Fix Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.
** Changed in: maas Status: Confirmed => In Progress ** Also affects: maas/2.2 Importance: Undecided Status: New ** Changed in: maas/2.2 Milestone: None => 2.2.3 ** Changed in: maas/2.2 Importance: Undecided => High ** Changed in: maas/2.2 Status: New => Triaged -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1642298 Title: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten. Status in curtin: Confirmed Status in MAAS: In Progress Status in MAAS 2.2 series: Triaged Status in grub2 package in Ubuntu: Fix Released Status in grub2 source package in Trusty: Triaged Status in grub2 source package in Xenial: Triaged Status in grub2 source package in Yakkety: Triaged Bug description: [Impact] Typically when you install Ubuntu on an EFI system, it installs a new default EFI boot entry that makes the system reboot directly into the OS. During MAAS installs, curtin is careful to disable that behavior. MAAS requires the default boot entry to remain PXE, so that it can direct the system to boot from disk or network as necessary. curtin does this by passing --no-nvram to grub-install when installing the bootloader. *Update*: newer curtin releases actually allow the creation of a new boot entry, but updates the boot menu to make PXE the default. That change is orthogonal to this bug. ***However***, this doesn't stop a new default boot entry from being added after deploy. If the user installs a grub package update or manually runs 'grub-install', booting from disk will become the default, and MAAS will lose control of the system. [Proposed Solution (er... glorified workaround)] The GRUB package in zesty now has support for setting the --no-nvram flag *persistently*. This is implemented via a debconf template (grub2/update_nvram). If curtin sets this flag to "false" during install, post-deploy grub updates will also pass the --no-nvram flag when running grub-install. This isn't a perfect solution - users can still call grub-install manually and omit this flag. [Test Case] - MAAS deploy an EFI system. - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg --print-architecture) - Reboot and observe that the system does not PXE boot. [Regression Risk] - The GRUB implementation does not change the defaults of the package. The user would need to opt-in to the "grub2/update_nvram=false". This option is also only presented to users who specifically request a low debconf priority (e.g. expert mode installs). - XXX curtin risk XXX To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1642298/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
