** Description changed:
- I have been very active in maas 1.7 lately with the introduction of
- support for arm64.
-
- Last night while debugging an issue with bug#
https://bugs.launchpad.net/maas/+bug/1377969
- I upgraded my environment from : 1.7.0~beta4+bzr3168-0ubuntu1~trusty1 ->
1.7.0~beta5+bzr3198-0ubuntu1
-
- I was purely focused on my x64 cartridges at the time, Today while
- preoccupied with other issues, I noticed that my arm64 && armhf nodes
- were failing to deploy in the Maas Gui. After having an ARMHF & ARM64
- node both fail on me while trying to complete some tasks, I began to
- investigate.
-
- I have found that during commissioning of the node all behaves as
- expected. The nodes drop into a ready status and can be Acquired ->
- Started.
-
- Once the user starts a nodes the image appears to go through the first
- stage of installation via curtin, the node then reboots, Upon booting
- off of the disk the following occurs in Maas 1.7 Beta5 :
-
- https://pastebin.canonical.com/118530/
-
- The first error I see is that cloud init fails to bring up eth0, which
- is followed by a traceback. which eventually leads to a failed
- deployment
-
-
- Now, here is the output from the same process, same boot images , same
- type of node (arm64) except run from maas 1.7 beta4
-
- https://pastebin.canonical.com/118529/
-
- As you can see, the node successfully deploys and we don't see a
- traceback.
-
- In both cases I am using the same boot-source :
http://maas.ubuntu.com/images/ephemeral-v2/releases/
- both servers also report the same boot-images when queried against their
corresponding UUID
-
- {
- "subarchitecture": "xgene-uboot",
- "osystem": "ubuntu",
- "label": "release",
- "architecture": "arm64",
- "release": "trusty",
- "purpose": "commissioning"
- },
- {
- "subarchitecture": "xgene-uboot",
- "osystem": "ubuntu",
- "label": "release",
- "architecture": "arm64",
- "release": "trusty",
- "purpose": "install"
- },
- {
- "subarchitecture": "xgene-uboot",
- "osystem": "ubuntu",
- "label": "release",
- "architecture": "arm64",
- "release": "trusty",
- "purpose": "xinstall"
- },
- {
- "subarchitecture": "xgene-uboot",
- "osystem": "ubuntu",
- "label": "release",
- "architecture": "arm64",
- "release": "trusty",
- "purpose": "diskless"
- },
-
- I can supply more information if required
+ [Impact]
+ On systems with multiple NICs on a single PCI function, lshw will fail to
show all of the NICs, and might associate the wrong MAC with an interface. This
is known to cause problems with MAAS functioning on such systems.
+ [Test Case]
+ Run lshw on a system with >1 NIC on a PCI function and observe the output.
+ [Regression Risk]
+ The cause of this issue is some deduplication code in lshw that checks to see
if the NIC it is scanning has already been registered. The included solution is
to also compare the MACs before assuming it is the same NIC. So, regression
risk could be that this code is broken (e.g. segfaults) or that there is a real
world case where multiple NICs may have the same MAC (hardware bridge?).
** Changed in: lshw (Ubuntu Trusty)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1379591
Title:
Moonshot nodes with Mellanox interfaces fail to deploy in maas 1.7
To manage notifications about this bug go to:
https://bugs.launchpad.net/lshw/+bug/1379591/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
