[Group.of.nepali.translators] [Bug 1642298] Re: UEFI Xenial install sets computer to boot from hard disk
Targeting for MAAS 2.3.0 since it sounds like MAAS changes are required. ** Changed in: maas Status: Invalid => Triaged ** Changed in: maas Importance: Undecided => High ** Changed in: maas Milestone: None => 2.3.0 -- 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: UEFI Xenial install sets computer to boot from hard disk Status in curtin: Confirmed Status in MAAS: 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
[Group.of.nepali.translators] [Bug 1553176] Re: BIND ignores nanoseconds field in timestamps, fails to load newer versions of zones on reload
** Also affects: maas/1.9 Importance: Undecided Status: New ** Changed in: maas/1.9 Milestone: None => 1.9.5 ** Changed in: maas/1.9 Status: New => In Progress ** Changed in: maas/1.9 Assignee: (unassigned) => LaMont Jones (lamont) ** Changed in: maas/1.9 Importance: Undecided => High -- 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/1553176 Title: BIND ignores nanoseconds field in timestamps, fails to load newer versions of zones on reload Status in BIND: Fix Released Status in MAAS: Fix Released Status in MAAS 1.9 series: In Progress Status in bind9 package in Ubuntu: Fix Released Status in bind9 source package in Trusty: Fix Committed Status in bind9 source package in Xenial: Fix Released Bug description: Since 2.6, linux has supported nanosecond granular time in stat(2) returns. BIND has a comment in the code that it might use it, but continues to ignore it. As of 9.9.3b2, named checks the time of (at least) zone files on disk (expanding to include include files in 9.10.0a2). Because the check is only done to a granularity of seconds, changing the zone file twice in the same second can cause BIND to decide that it need not reload the zone, even though it is out of date. [Impact] * If a zone file is changed (generally by automated processes) more than once in a second, bind9 happily thinks it has already loaded the zone. A trivial demonstration of the bug can be seen at paste.ubuntu.com/23921121/ -- http://paste.ubuntu.com/23921176/ is the same test with the fixed code. Making this a test case is somewhat problematic in that it needs to make sure that they happen inside of the same second. * MAAS is exactly the sort of use case that hits this bug. * The upload changes BIND's utility function to actual use the st_mtim.tv_nsec instead of '0'. [Test Case] * See the pastebin above. (Change a zone file and reload it, and then do it again less than a second later.) [Regression Potential] * Ignoring the whole "rebuilds sometimes break things", the most likely regression would be one where something was either relying on BIND not reloading the dozone (unlikely), or otherwise relying on the modify time on a zone file to some arbitrary value. [Other Info] This bug was fixed in 1:9.10.3.dfsg.P2-5, which landed in xenial March 2016. To manage notifications about this bug go to: https://bugs.launchpad.net/bind/+bug/1553176/+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 1651602] Re: [2.1.1] MAAS has nvme0n1 set as boot disk, curtin fails
After further troubleshooting with cgregan, we've further narrowed this down. We ran the following script on the node that was having trouble: https://gist.github.com/pontillo/0b92a7da2fba43fb5dce705be2dcf38b Unlike all the other devices MAAS works with, the Intel NVMe device reports a serial number that cannot be found anywhere in /dev/disk/by- id/*. When curtin is supplied a serial number, it uses a heuristic to find the device as follows: http://bazaar.launchpad.net/~curtin- dev/curtin/trunk/view/435/curtin/commands/block_meta.py#L270 http://bazaar.launchpad.net/~curtin- dev/curtin/trunk/view/435/curtin/block/__init__.py#L601 So arguably, this is a bug in the Intel NVMe serial number; the way it populates /dev/disk/* leaves much to be desired. This is *arguably* a bug in curtin (and maybe MAAS, since we knowingly use the serial number even though `udevadm` can tell us that the serial cannot be found anywhere in /dev/disk/by-id/*), in that we could do a better job dealing with devices backed by not-so-robust kernel drivers. But I think we shouldn't encourage bad behavior on the part of driver writers, so I'm on the fence about whether or not we should fix it. But mostly, I would argue that this is a bug in the Intel NVMe driver. The way they expose the device to userland is non-standard and arguably broken. When we ran `udevadm info -q all -n nvme0n1` on the device, we got the following pseudo-output: nvme0n1: P: /devices/pci:00/:00:xx.0/:xx:00.0/nvme/nvme0/nvme0n1 N: nvme0n1 S: SSDxx_CVMDxx S: disk/by-id/nvme-INTEL E: DEVLINKS=/dev/disk/by-id/nvme-INTEL /dev/SSDxx_CVMDxx E: DEVNAME=/dev/nvme0n1 E: DEVPATH=/devices/pci:00/:00:xx.0/:xx:00.0/nvme/nvme0/nvme0n1 E: DEVTYPE=disk E: ID_SERIAL=INTEL SSDxx_CVMDxx E: ID_SERIAL_SHORT=CVMDxx E: MAJOR=259 E: MINOR=0 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=xxx You can see by the lines that start with "S:" and the "DEVLINKS=" line that the way this device is exposed is very non-standard. One would expect /dev/disk/by-id/* to contain a DEVLINK containing the serial number. Instead they expose a 'nvme-INTEL' link, which is (IMHO) a critical bug, because anyone expecting the things in /dev/disk/by-id/* to be unique will be in for a big surprise when they add a second NVMe device to a machine. ** Also affects: curtin Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Invalid => New ** Changed in: linux (Ubuntu Xenial) Status: Fix Committed => New -- 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/1651602 Title: Intel NVMe driver does not expose consistent links in /dev/disk/by-id Status in curtin: New Status in MAAS: Won't Fix Status in linux package in Ubuntu: Incomplete Status in linux source package in Xenial: Incomplete Bug description: MAAS Version 2.1.1+bzr5544-0ubuntu1 (16.10.1) Deploying Xenial Nodes 1) Deploy MAAS 2.1.1 on Yakkety 2) Associate Juju 2.1 beta3 3) Juju deploy Kubernetes Core Nodes begin to deploy but fail Installation failed with exception: Unexpected error while running command. Command: ['curtin', 'block-meta', 'custom'] Exit code: 3 Reason: - Stdout: b"no disk with serial 'CVMD434500BN400AGN' found\n" To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1651602/+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
