[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2021-05-11 Thread Lee Trager
Upon further testing I was able to confirm Dimitri's suspicion that the
-no-reboot option in LXD is causing the SecureBoot failures. I have
reported this to LXD[1] and will work to resolve that separately. I am
able to get SecureBoot working when using libvirt with signed OVMF using
grub-efi-amd64-signed_1.169+2.04-1ubuntu45_amd64.deb and shim-
signed_1.47+15.4-0ubuntu2_amd64.deb from Impish. I was able to deploy
both 20.04 and 21.04 with SecureBoot enabled as verified by mokutil
--sb-state.

Our currently policy in MAAS is to only add bootloaders from an LTS in
main to the stream. Is there any ETA as to when the shim and grub will
be backported to Focal?

[1] https://github.com/lxc/lxd/issues/8770

** Bug watch added: LXD bug tracker #8770
   https://github.com/lxc/lxd/issues/8770

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2021-05-06 Thread Lee Trager
I just tried retesting with grub-efi-
amd64-signed_1.169+2.04-1ubuntu45_amd64.deb and shim-
signed_1.47+15.4-0ubuntu2_amd64.deb from Impish. I made sure those
versions of GRUB and the shim were served by MAAS and that they were
both used in the local deployed environment. During testing I added 'set
debug="all"' to grub.cfg coming from MAAS as well as the local grub.cfg.
I also made sure 'earlyprintk=efi' was passed to the kernel in the local
grub.cfg.

I don't think the kernel is ever being loaded. The last message I get is
"EFI stub: UEFI Secure Boot is enabled." The system then hangs and never
proceeds.

** Attachment added: "lxd-vm.log.xz"
   
https://bugs.launchpad.net/maas/+bug/1865515/+attachment/5495355/+files/lxd-vm.log.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] Re: grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-05-05 Thread Lee Trager
When you added the ARM64 machine are you including the boot MAC address
or just the IPMI credentials? When you add just the IPMI credentials the
machine actually goes into enlistment but MAAS detects its a known
machine based on IPMI credenitals when the BMC is detected.

The associated branch updates the default grub.cfg file which is stored
with all boot images. These files only get updated when a new image is
found on images.maas.io or whatever your mirror is. To force the update
you can run

sudo rm -rf /var/lib/maas/boot-resources/*
sudo systemctl restart maas-rackd

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] Re: grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-05-04 Thread Lee Trager
The attached MP should fix this in newer versions of MAAS. We still may
want to change the default grub.cfg for older versions of MAAS as I'm
not sure how far we will be backporting it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] Re: grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-05-04 Thread Lee Trager
lp:maas-images produces the bootloaders stream. It was previously
pointed to Bionic for i386(pxelinux), amd64(shim+grub-signed), and
arm64(grub) while PPC64(grub) is pointed to Xenial. In an attempt to get
secure boot working I upgraded i386, amd64, and arm64 to Focal. arm64
and PPC64 had their grub "built" with grub-mkimage as they don't use the
signed package. Part of this process included a custom grub.cfg which
did the right thing. Our build host is still using Precise and the team
managing it doesn't have time to upgrade it. I noticed that grub-signed
is now available for arm64 so I moved arm64 to shim+grub-signed.

We test all changes to the stream however our current process doesn't
test enlistment, only commissioning, testing, and deployment. We noticed
this bug in our CI and filed it. A resolution is being discussed this
week at the sprint.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] Re: grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-05-04 Thread Lee Trager
MAAS expects the Debian architecture to be used. We could create a map
for it and respond as you suggest. However this would only fix new
versions of MAAS. MAAS started using bootloaders from the stream in MAAS
2.1. We no longer support MAAS < 2.5, those versions would remain
broken. It would most likely take a few months to back port and qualify
to MAAS 2.5-2.9. Patching GRUB to try what MAAS expects would be the
fastest solution to get a fix to all of our users.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] Re: grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-04-23 Thread Lee Trager
When MAAS gets the TFTP/HTTP request for grub.cfg it doesn't know what
the client architecture is.  MAAS identifies the machine based on the
requested URL. MAAS comes with a default grub.cfg[1] which tries loading
/grub/grub.cfg-${net_default_mac} and if that fails /grub/grub.cfg-
default-amd64. Machines which have been added to MAAS will match on
grub.cfg-${net_default_mac} which already has the architecture defined
in Postgres. During enlistment the machine is unknown so /grub/grub.cfg-
default-amd64 is used. /grub/grub.cfg-default-amd64 always returns the
kernel and initrd for AMD64.

This wasn't a problem previously on ARM64 because we were building an
unsigned GRUB which embedded a grub.cfg that tried
/grub/grub.cfg-${net_default_mac} then /grub/grub.cfg-default-arm64[2].

MAAS responds to the following:
1. grub/grub.cfg- - MAC address in IEEE 802 colon-seperated format. There 
is a note in MAAS source that GRUB will only send MAC addresses in this 
format[1]. Due to this dash separated MAC is not supported.
2. grub/grub.cfg-default- - ARCH is a Debian architecture supported by 
MAAS(amd64, arm64, etc)
3. grub/grub.cfg - This simply tries 1 then 2.

While its possible to add support for other formats GRUB comes from the
MAAS stream. We can't force existing users to upgrade.

[1] 
https://git.launchpad.net/maas/tree/src/provisioningserver/boot/uefi_amd64.py?h=2.9#n22
[2] 
https://git.launchpad.net/maas-images/tree/conf/bootloaders.yaml?id=10c44123886a03f828ee19675164ced83928ba27#n46

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] Re: grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-04-21 Thread Lee Trager
We have noticed that this is breaking enlistment in MAAS on ARM64. Using
${grub_cpu} may work but MAAS expects Debian architectures.

[1] https://www.gnu.org/software/grub/manual/grub/grub.html#grub_005fcpu

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2021-04-19 Thread Lee Trager
I'm using the default LXD settings, attached is qemu.conf.

** Attachment added: "qemu.conf"
   
https://bugs.launchpad.net/maas/+bug/1865515/+attachment/5489916/+files/qemu.conf

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2021-04-19 Thread Lee Trager
I was told that the latest SHIM/GRUB from Hirsute may have fixed this
issue. It looks like chain loading from network GRUB to local GRUB works
but the VM turns off when it tries to start the kernel. Attached is GRUB
output with debug="all"

My test setup is as follows:
grub over the network and local: 2.04-1ubuntu45
shim over the network and local: 1.46+15.4-0ubuntu1
OS: Ubuntu 21.04
Machine: LXD VM 4.0.5
qemu command: /snap/lxd/19647/bin/qemu-system-x86_64 -S -name lxd-vm -uuid 
f5fec2be-21c7-4ffb-847f-f88589c06686 -daemonize -cpu host -nographic -serial 
chardev:console -nodefaults -no-reboot -no-user-config -sandbox 
on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny 
-readconfig /var/snap/lxd/common/lxd/logs/maas_lxd-vm/qemu.conf -pidfile 
/var/snap/lxd/common/lxd/logs/maas_lxd-vm/qemu.pid -D 
/var/snap/lxd/common/lxd/logs/maas_lxd-vm/qemu.log -chroot 
/var/snap/lxd/common/lxd/virtual-machines/maas_lxd-vm -smbios 
type=2,manufacturer=Canonical Ltd.,product=LXD -runas lxd 

** Attachment added: "secure-boot.log"
   
https://bugs.launchpad.net/maas/+bug/1865515/+attachment/5489915/+files/secure-boot.log

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1923268] [NEW] grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac} before /grub/grub.cfg

2021-04-09 Thread Lee Trager
Public bug reported:

MAAS uses the signed network GRUB bootloader when a machine network
boots on AMD64 and ARM64. The configuration MAAS produces depends on the
machine which are identified by MAC address. The default grub.cfg in the
boot loader downloads /grub/grub.cfg from the remote host. As that
doesn't provide the MAC address MAAS provides a default configuration
file:

configfile /grub/grub.cfg-${net_default_mac}
configfile /grub/grub.cfg-default-amd64

There are two issues with this:

1. This causes an additional unnecessary request.
2. It is assumed an known machine is amd64.

Can the default grub.cfg embedded in grubnet.efi be updated to

configfile /grub/grub.cfg-${net_default_mac}
configfile /grub/grub.cfg-default-
configfile /grub/grub.cfg

This would be similar to what PXELinux[1] does.

[1] https://wiki.syslinux.org/wiki/index.php?title=PXELINUX

** Affects: grub2-signed (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923268

Title:
  grubnet default grub.cfg should try /grub/grub.cfg-${net_default_mac}
  before /grub/grub.cfg

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1923268/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1918970] Re: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration

2021-03-31 Thread Lee Trager
** Changed in: linux (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918970

Title:
  Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition -
  no manual nor automatic qeth device configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1918970/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1916073] Re: qemu-system-arm should depend on qemu-efi

2021-02-19 Thread Lee Trager
** Also affects: maas/2.9
   Importance: Undecided
   Status: New

** Changed in: maas/2.9
   Status: New => In Progress

** Changed in: maas/2.9
 Assignee: (unassigned) => Lee Trager (ltrager)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1916073

Title:
  qemu-system-arm should depend on qemu-efi

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1916073/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1916073] Re: qemu-system-arm should depend on qemu-efi

2021-02-19 Thread Lee Trager
ah I see whats going on. MAAS passes a list of packages for cloud-init
to install. cloud-init doesn't install recommends. I'll add it to the
package list in MAAS.

** Also affects: maas
   Importance: Undecided
   Status: New

** Changed in: maas
   Status: New => In Progress

** Changed in: maas
 Assignee: (unassigned) => Lee Trager (ltrager)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1916073

Title:
  qemu-system-arm should depend on qemu-efi

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1916073/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1916073] [NEW] qemu-system-arm should depend on qemu-efi

2021-02-18 Thread Lee Trager
Public bug reported:

I used MAAS to deploy a VM host. When MAAS does this it installs the
libvirt-daemon-system and libvirt-clients packages which pull in qemu-
system-arm on ARM64. I tried to use MAAS to create a virtual machine but
this failed with

Failed to open file '/usr/share/AAVMF/AAVMF_CODE.fd': No such file or
directory

Manually installing the qemu-efi package fixes the issue.

AMD64 and PPC64 don't require the qemu-efi package because by default
they don't emulate UEFI. Because ARM64 does emulate UEFI by default the
qemu-efi package should be required by qemu-system-arm.

** Affects: qemu (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1916073

Title:
  qemu-system-arm should depend on qemu-efi

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1916073/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908452] Re: MAAS stops working and deployment fails after `Loading ephemeral` step

2021-02-01 Thread Lee Trager
@dannf - Thanks for the great deep dive!

It seems the issue is in python3-simplestreams. According to [1] "Nearly
all production code should use this parameter in nearly all requests.
Failure to do so can cause your program to hang indefinitely"

The timeout needs to be set in RequestsUrlReader which is fairly deep in
SimpleStreams code, MAAS does not directly interact with it at all.
simplestreams uses Urllib2UrlReader as an alternative if requests isn't
available and no timeout is set there either.
RequestsUrlReader/Urllib2UrlReader is called by UrlMirrorReader which
MAAS does call.

We need to figure out a good default timeout value for both
RequestsUrlReader and Urllib2UrlReader. We also need to determine
whether this should be configurable by the caller or not, MAAS will most
likely use the default value.

[1] https://requests.readthedocs.io/en/master/user/quickstart/#timeouts

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908452

Title:
  MAAS stops working and deployment fails after `Loading ephemeral` step

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1908452/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1904793] Re: upower abruptly thinks battery has gone to 1% and hibernates

2021-01-12 Thread Lee Trager
Upstream bug reported at
https://gitlab.freedesktop.org/upower/upower/-/issues/136

** Bug watch added: gitlab.freedesktop.org/upower/upower/-/issues #136
   https://gitlab.freedesktop.org/upower/upower/-/issues/136

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1904793

Title:
  upower abruptly thinks battery has gone to 1% and hibernates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1904793/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2021-01-11 Thread Lee Trager
We're in a bit of a bind here, even if we do fix LP:1906379 and
LP:1910600 there is no way for MAAS to fix existing deployments. Meaning
unilaterally using "exit 1" will break existing deployments which users
will have to manually fix.

Is it at all possible to create a grub.cfg which can detect if there is
a UEFI local boot entry which is next? If so we could use "exit 1" if
there is an entry and fall back onto the exiting grub.cfg if there
isn't.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2021-01-07 Thread Lee Trager
Using "exit 1" to to chainboot breaks if there is no UEFI boot entry.
MAAS currently has two known bugs where this is the case. There may be
more, we need to test all operating systems MAAS supports.

LP:1906379 - Ubuntu is removing the UEFI boot entry during shutdown for CentOS.
LP:1910600 - MAAS does not create a UEFI boot entry for VMware ESXi 6.7

If we apply the patch in #41 we will be breaking existing deployments.
There is no way for MAAS to fix this, the user will have to manually
login and configure the system.

config.local.amd64.template originally chainbooted to the operating
system based on the operating system name. We had to change this because
MAAS has no way to know what operating system a custom image is or how
to handle when RHEL changed its UEFI path. For example is custom/myimage
Ubuntu, CentOS, Windows or VMware?

I'm hesitant to use this fix as we will likely be breaking existing
deployments.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1906344] Re: grub is unable to chainboot from network to SATA drive

2020-12-01 Thread Lee Trager
** Description changed:

  Machines which are managed by MAAS are configured to always network
  boot. When an operating system is deployed grub is sent[1] a
  configuration file which searches drives for recognized boot loaders.
  When the local disk is a SATA drive this process is not working. The
  config exits at the end to fallback to booting the next configured
- device but this config does not always exist. In that case the
- deployment fails.
+ device but this config does not always exist(e.g LP:1906379). In that
+ case the deployment fails.
  
  I've verified this happens with grub from
  Focal(1.142.9+2.04-1ubuntu26.7) and Bionic(1.93.22+2.02-2ubuntu8.20).
  
  Reproduction:
  1. Create a KVM which uses an emulated SATA drive and UEFI firmware.
  2. Add the machine and commission it in MAAS
  3. Try deploying any operating system. CentOS 8 currently fails to deploy 
because it does not create a UEFI entry.
  
  [1]
  
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906344

Title:
  grub is unable to chainboot from network to SATA drive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1906344/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1906344] Re: grub is unable to chainboot from network to SATA drive

2020-11-30 Thread Lee Trager
** Description changed:

  Machines which are managed by MAAS are configured to always network
  boot. When an operating system is deployed grub is sent[1] a
  configuration file which searches drives for recognized boot loaders.
  When the local disk is a SATA drive this process is not working. The
  config exits at the end to fallback to booting the next configured
  device but this config does not always exist. In that case the
  deployment fails.
  
+ I've verified this happens with grub from
+ Focal(1.142.9+2.04-1ubuntu26.7) and Bionic(1.93.22+2.02-2ubuntu8.20).
+ 
  Reproduction:
  1. Create a KVM which uses an emulated SATA drive and UEFI firmware.
  2. Add the machine and commission it in MAAS
  3. Try deploying any operating system. CentOS 8 currently fails to deploy 
because it does not create a UEFI entry.
  
  [1]
  
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906344

Title:
  grub is unable to chainboot from network to SATA drive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1906344/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1906344] [NEW] grub is unable to chainboot from network to SATA drive

2020-11-30 Thread Lee Trager
Public bug reported:

Machines which are managed by MAAS are configured to always network
boot. When an operating system is deployed grub is sent[1] a
configuration file which searches drives for recognized boot loaders.
When the local disk is a SATA drive this process is not working. The
config exits at the end to fallback to booting the next configured
device but this config does not always exist. In that case the
deployment fails.

I've verified this happens with grub from
Focal(1.142.9+2.04-1ubuntu26.7) and Bionic(1.93.22+2.02-2ubuntu8.20).

Reproduction:
1. Create a KVM which uses an emulated SATA drive and UEFI firmware.
2. Add the machine and commission it in MAAS
3. Try deploying any operating system. CentOS 8 currently fails to deploy 
because it does not create a UEFI entry.

[1]
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template

** Affects: grub2 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906344

Title:
  grub is unable to chainboot from network to SATA drive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1906344/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1904793] Re: upower abruptly thinks battery has gone to 1% and hibernates

2020-11-30 Thread Lee Trager
I've been monitoring upower and I think the problem is it is incorrectly
detecting the number of batteries in my laptop. I only have one yet
upower detects 5 power sources. One of them is a DisplayDevice which
normally shows the same amount of battery as my system battery.
Sometimes that drops to 1% or 0%. I've had my laptop plugged in all day
here are two upower -d dumps from within the last 5 minutes. Notice in
the first dump /org/freedesktop/UPower/devices/DisplayDevice has 0%
battery despite the laptop being plugged in. On the second it has the
same engery, energy-full, and percentage as
/org/freedesktop/UPower/devices/battery_BAT0.

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:  AC
  power supply: yes
  updated:  Mon 30 Nov 2020 02:36:20 PM PST (13554 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  yes
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  BAT0
  vendor:   Celxpert
  model:5B10V98091
  serial:   1695
  power supply: yes
  updated:  Mon 30 Nov 2020 06:20:22 PM PST (112 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   charging
warning-level:   none
energy:  0 Wh
energy-empty:0 Wh
energy-full: 654.79 Wh
energy-full-design:  80.4 Wh
energy-rate: 0 W
voltage: 7.189 V
percentage:  0%
capacity:88.4453%
technology:  lithium-polymer
icon-name:  'battery-caution-charging-symbolic'
  History (charge):
1606789222  0.000   charging

Device: /org/freedesktop/UPower/devices/line_power_ucsi_source_psy_USBC000o001
  native-path:  ucsi-source-psy-USBC000:001
  power supply: yes
  updated:  Fri 27 Nov 2020 02:59:19 PM PST (271375 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  no
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/line_power_ucsi_source_psy_USBC000o002
  native-path:  ucsi-source-psy-USBC000:002
  power supply: yes
  updated:  Fri 27 Nov 2020 02:59:18 PM PST (271376 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  no
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply: yes
  updated:  Mon 30 Nov 2020 06:20:22 PM PST (112 seconds ago)
  has history:  no
  has statistics:   no
  battery
present: yes
state:   charging
warning-level:   none
energy:  0 Wh
energy-full: 654.79 Wh
energy-rate: 0 W
percentage:  0%
icon-name:  'battery-caution-charging-symbolic'

Daemon:
  daemon-version:  0.99.11
  on-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: HybridSleep



$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:  AC
  power supply: yes
  updated:  Mon 30 Nov 2020 02:36:20 PM PST (13733 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  yes
icon-name:  'ac-adapter-symbolic'

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  BAT0
  vendor:   Celxpert
  model:5B10V98091
  serial:   1695
  power supply: yes
  updated:  Mon 30 Nov 2020 06:24:22 PM PST (51 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   fully-charged
warning-level:   none
energy:  71.71 Wh
energy-empty:0 Wh
energy-full: 654.79 Wh
energy-full-design:  80.4 Wh
energy-rate: 0 W
voltage: 17.173 V
percentage:  99%
capacity:88.4453%
technology:  lithium-polymer
icon-name:  'battery-full-charged-symbolic'

Device: /org/freedesktop/UPower/devices/line_power_ucsi_source_psy_USBC000o001
  native-path:  ucsi-source-psy-USBC000:001
  power supply: yes
  updated:  Fri 27 Nov 2020 02:59:19 PM PST (271554 seconds ago)
  has history:  no
  has statistics:   no
  line-power
warning-level:   none
online:  no
icon-name:  'ac-adapter-symbolic'

Device: 

[Bug 1904793] [NEW] upower abruptly thinks battery has gone to 1% and hibernates

2020-11-18 Thread Lee Trager
Public bug reported:

Whenever I go on battery after 20-30 minutes upower will very abruptly
think my battery is at 1% and force my laptop to hibernate. This seems
to happen at random times, I've seen it when my battery was reported to
be 90%, 76%, 45%, 25%, etc. If I try to resume Ubuntu locks up forcing
me to hard reset the machine. I suspect this is because upower thinks my
battery is still at 1% when its not. My laptops firmware correctly
reports the battery level and shows that I have plenty of power
remaining. The last few times this happened I kept powertop up which
shows that I do have plenty of power even when upower thinks I have
none. Essentially this makes my laptop unusable on battery.

Laptop: Lenovo X1 Carbon Extreme Gen 2

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: upower 0.99.11-2
ProcVersionSignature: Ubuntu 5.8.0-29.31-generic 5.8.14
Uname: Linux 5.8.0-29-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
ApportVersion: 2.20.11-0ubuntu50.1
Architecture: amd64
CasperMD5CheckResult: skip
Date: Wed Nov 18 13:59:24 2020
InstallationDate: Installed on 2019-12-29 (325 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191220)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: upower
UpgradeStatus: Upgraded to groovy on 2020-10-23 (25 days ago)

** Affects: upower (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug groovy

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1904793

Title:
  upower abruptly thinks battery has gone to 1% and hibernates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1904793/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1741913] Re: [master] Twisted seems to not handle disconnect from client correctly

2020-10-30 Thread Lee Trager
** Changed in: maas
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1741913

Title:
  [master] Twisted seems to not handle disconnect from client correctly

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1741913/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1741913] Re: [master] Twisted seems to not handle disconnect from client correctly

2020-10-26 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b7 => 2.9.0b8

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1741913

Title:
  [master] Twisted seems to not handle disconnect from client correctly

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1741913/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1876258] Re: ubuntu 20.04 pxe installation fails with no such file or directory /dev/disk/by-id exception

2020-10-26 Thread Lee Trager
** Changed in: maas
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258

Title:
  ubuntu 20.04 pxe installation fails with no such file or directory
  /dev/disk/by-id exception

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1876258/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898808] Re: [maas][focal]unable to deploy 20.04(focal) w/ default kernel for sut after images update on Oct 5

2020-10-20 Thread Lee Trager
Last week we split the image stream hosted at images.maas.io into
candidate and stable. daily now redirects to stable. There have been no
changes to the images, only the label has been changed. lp:maas-images
only downloads the SquashFS from http://cloud-images.ubuntu.com/ and
pulls the kernel out of the Debian package. It has no control over the
contents of the image or kernel.

** No longer affects: maas-images

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898808

Title:
  [maas][focal]unable to deploy 20.04(focal) w/ default kernel for sut
  after images update on Oct 5

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1898808/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1876258] Re: ubuntu 20.04 pxe installation fails with no such file or directory /dev/disk/by-id exception

2020-10-16 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b4 => 2.9.0b7

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258

Title:
  ubuntu 20.04 pxe installation fails with no such file or directory
  /dev/disk/by-id exception

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1876258/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-10-16 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b4 => 2.9.0b7

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-10-16 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b4 => 2.9.0b7

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-09-19 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3

** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1876258] Re: ubuntu 20.04 pxe installation fails with no such file or directory /dev/disk/by-id exception

2020-09-19 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3

** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258

Title:
  ubuntu 20.04 pxe installation fails with no such file or directory
  /dev/disk/by-id exception

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1876258/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-09-19 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3

** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-09-10 Thread Lee Trager
I mean the output of /sys/class/dmi/id/product_uuid. However I'm not
sure how reliable that is. Since I made that comment we've had multiple
users report(LP:1893690) some vendors are handing out duplicate UUIDs.
MAAS handles this by ignoring any UUID which has been duplicated.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-09-10 Thread Lee Trager
MAAS tries to do

(FW) -> shim(net) -> grub(net) -> shim(local) -> grub(local)

When grub(net) runs MAAS send it this[1] config which searches for the
local bootloader as we don't know where it is. It prefers chainloading
the shim but will fall back on grub if that isn't found.

The reason we chainload the local shim is because we need to support
secure boot for multiple operating systems. My understanding of the shim
is that it only stores the keys from the OS vendor that provides it, not
multiple vendors. MAAS officially supports Ubuntu, CentOS, RHEL,
Windows, and VMware. Users have gotten other operating systems to work
as well and there has been talk of adding SUSE support.

Secure boot must work for every operating system MAAS supports, not just
Ubuntu.

[1]
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895044] Re: update_nvram defaults to false, not true as per docs

2020-09-09 Thread Lee Trager
SolutionsQA and the MAAS CI verify that operations like commissioning
and deploying work. AFAIK neither verify the deployed environment, just
that the CI can SSH into it. Since both CIs verify that MAAS doesn't go
down while testing this test case isn't hit.

I'll leave this open for MAAS to add NVRAM verification to the MAAS CI.

** Changed in: maas
Milestone: 2.9.0b2 => None

** Tags added: maas-ci

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895044

Title:
  update_nvram defaults to false, not true as per docs

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1895044/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-09-08 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1859751] Re: Piston missing support for Django 2.2

2020-09-08 Thread Lee Trager
** Changed in: maas
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1859751

Title:
  Piston missing support for Django 2.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1859751/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1881821] Re: MAAS does not properly detect max interface speed for interfaces which use multiple phyiscal ports(Cisco UCS B200 M5 blade)

2020-09-08 Thread Lee Trager
** Changed in: maas
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881821

Title:
  MAAS does not properly detect max interface speed for interfaces which
  use multiple phyiscal ports(Cisco UCS B200 M5 blade)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1881821/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1876258] Re: ubuntu 20.04 pxe installation fails with no such file or directory /dev/disk/by-id exception

2020-09-08 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258

Title:
  ubuntu 20.04 pxe installation fails with no such file or directory
  /dev/disk/by-id exception

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1876258/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-09-08 Thread Lee Trager
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1891331] Re: ipmi-config command not found in snap

2020-09-08 Thread Lee Trager
** Changed in: maas
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1891331

Title:
  ipmi-config command not found in snap

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1891331/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1892032] Re: RM djorm-ext-pgarray, not needed since django 1.8 has it all

2020-09-08 Thread Lee Trager
** Changed in: maas
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1892032

Title:
  RM djorm-ext-pgarray, not needed since django 1.8 has it all

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1892032/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1876258] Re: ubuntu 20.04 pxe installation fails with no such file or directory /dev/disk/by-id exception

2020-08-21 Thread Lee Trager
As per Ryan's comment in LP:1891251 MAAS should ensure block devices are
created with serial numbers. This is possible with libvirt however we
may need LXD to add support for this.

** Also affects: maas
   Importance: Undecided
   Status: New

** Changed in: maas
   Status: New => Confirmed

** Changed in: maas
   Importance: Undecided => High

** Also affects: maas/2.8
   Importance: Undecided
   Status: New

** Changed in: maas/2.8
   Status: New => Confirmed

** Changed in: maas/2.8
   Importance: Undecided => High

** Changed in: maas
Milestone: None => 2.9.0b1

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258

Title:
  ubuntu 20.04 pxe installation fails with no such file or directory
  /dev/disk/by-id exception

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1876258/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1869116] Re: smartctl-validate is borked in a recent release

2020-07-17 Thread Lee Trager
** No longer affects: util-linux (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116

Title:
  smartctl-validate is borked in a recent release

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxd/+bug/1869116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1869116] Re: smartctl-validate is borked in a recent release

2020-07-17 Thread Lee Trager
** Also affects: maas/2.7
   Importance: Undecided
   Status: New

** Changed in: maas/2.7
   Importance: Undecided => Critical

** Changed in: maas/2.7
 Assignee: (unassigned) => Lee Trager (ltrager)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116

Title:
  smartctl-validate is borked in a recent release

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxd/+bug/1869116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1869116] Re: smartctl-validate is borked in a recent release

2020-07-16 Thread Lee Trager
** Bug watch added: LXD bug tracker #7665
   https://github.com/lxc/lxd/issues/7665

** Changed in: lxd
   Status: Fix Released => Unknown

** Changed in: lxd
 Remote watch: LXD bug tracker #7096 => LXD bug tracker #7665

** Changed in: maas
   Importance: Undecided => High

** Changed in: maas/2.8
   Importance: Undecided => High

** Changed in: maas
   Importance: High => Critical

** Changed in: maas/2.8
   Importance: High => Critical

** Changed in: maas
Milestone: None => 2.9.0b1

** Changed in: maas
 Assignee: (unassigned) => Lee Trager (ltrager)

** Changed in: maas/2.8
 Assignee: (unassigned) => Lee Trager (ltrager)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116

Title:
  smartctl-validate is borked in a recent release

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxd/+bug/1869116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1869116] Re: smartctl-validate is borked in a recent release

2020-07-08 Thread Lee Trager
I was able to reproduce this bug by emulating an IDE in QEMU device and
running the smartctl-validate test. I have filed an upstream bug as
well.

https://github.com/karelzak/util-linux/issues/1098

** Bug watch added: github.com/karelzak/util-linux/issues #1098
   https://github.com/karelzak/util-linux/issues/1098

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116

Title:
  smartctl-validate is borked in a recent release

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxd/+bug/1869116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-07-07 Thread Lee Trager
> Not sure if we want a feature to automatically scan/find grub.cfg on
remote host by ip/mac/uuid/etc:

Currently MAAS only specifies the path to the bootloader, not the
bootloader config. It expects the bootloader will automatically request
the config from where the bootloader was downloaded from. Right now that
is /grub/grub.cfg. That file attempts to chainload
/grub/grub.cfg-${net_default_mac} and if that fails
/grub/grub.cfg-default-amd64. MAAS could also respond to
/grub/grub.cfg-$uuid as we have that information as well. Having
grub do that automatically would remove a request and a level of
chainloading.

https://git.launchpad.net/maas/tree/src/provisioningserver/boot/uefi_amd64.py

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-06-12 Thread Lee Trager
By default an LXD VM boots from the disk first. However you can change
the boot order by adding "boot.priority" to your devices. The device
with the highest number boots first.

LXD devices config for booting off the boot disk.
devices:
  eth0:
name: eth0
nictype: bridged
parent: br0
type: nic
  root:
path: /
pool: default
size: "80"
type: disk

LXD devices config for booting off the network first.
devices:
  eth0:
boot.priority: "1"
name: eth0
nictype: bridged
parent: br0
type: nic
  root:
boot.priority: "0"
path: /
pool: default
size: "80"
type: disk

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1881821] Re: MAAS does not properly detect max interface speed for interfaces which use multiple phyiscal ports(Cisco UCS B200 M5 blade)

2020-06-10 Thread Lee Trager
** No longer affects: maas/2.7

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881821

Title:
  MAAS does not properly detect max interface speed for interfaces which
  use multiple phyiscal ports(Cisco UCS B200 M5 blade)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1881821/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-06-03 Thread Lee Trager
Please provide remote artifacts:
All bootloader files are pulled from the Bionic archive and provided on 
images.maas.io by lp:maas-images. bootloaders.yaml[1] describes what files are 
pulled from what packages. You can download the tars at[2] 

Please provide local artifacts:
The local artifacts are from the deploy OS. So for Ubuntu its whatever 
shim/grub is in the archive for that version of Ubuntu. Same goes for CentOS, 
VMware, Windows, etc.

Keep in mind once HTTP boot is set the remote GRUB drops to the command
line before loading the remote grub.cfg. I can only precede with the
manual steps detailed above.

Please provide reproducer steps:
1. Install MAAS
2. Configure an UEFI virtual machine to use with MAAS. I would suggest manually 
creating a UEFI VM with libvirt and adding it to MAAS as a machine.
3. Commission the VM and enable SSH so you can enable HTTP boot
4. SSH into the VM and put HTTP boot before TFTP as described above.
5. Shutdown the machine.
6. Try to deploy any operating system

Please provide details how local artifacts were installed:
Local artifacts are installed by Curtin which gets them from the Ubuntu archive 
when installing Ubuntu or CentOS archive when installing CentOS.

Please provide list of certs trusted by the node's firmware:
Due to LP:1865515 secure boot was disabled to produce this bug.

[1] https://git.launchpad.net/maas-images/tree/conf/bootloaders.yaml
[2] https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/


** Changed in: grub2 (Ubuntu)
   Status: Incomplete => New

** Changed in: shim-signed (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1881821] Re: Kernel does not report interface speed correctly for Cisco UCS B200 M5 blade

2020-06-03 Thread Lee Trager
MAAS 2.7 introduced network testing. As part of network testing we added
the following features which require accurate interface and link speed
information.

1. The interface and uplink speeds are now shown in the API and over the UI.
2. MAAS now warns when an interface is connected to an uplink which is slower 
than its maximum supported speed.
3. Users may now acquire machines based on its uplink speed.

I could stop verifying that link speed >= max interface speed however
that will mean 1 is incorrect and 2 is broken. I understand that some
interfaces achieve higher speeds by using more physical ports but
neither ethtool nor LXD give any information on this.

Does anyone know the proper way to calculate the maximum supported
interface speed on a device like this?

** Summary changed:

- Kernel does not report interface speed correctly for Cisco UCS B200 M5 blade
+ MAAS does not properly detect max interface speed for interfaces which use 
multiple phyiscal ports(Cisco UCS B200 M5 blade)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881821

Title:
  MAAS does not properly detect max interface speed for interfaces which
  use multiple phyiscal ports(Cisco UCS B200 M5 blade)

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1881821/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-06-03 Thread Lee Trager
All bootloader files are pulled from the archive and provided on
images.maas.io by lp:maas-images. bootloaders.yaml describes what files
are pulled from what packages.

https://git.launchpad.net/maas-images/tree/conf/bootloaders.yaml

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-06-03 Thread Lee Trager
The MAAS environment I've been using to reproduce this is virtual. I
have MAAS running in an LXD container connected to an LXD Pod. To
recreate this environment you'll have to install MAAS 2.8, python-pylxd
from github(if using the Debian packages), and apply this[1] patch to
reenable secure boot. After MAAS is setup you'll need to configure LXD
to accept remote connections to be able to add it as a MAAS Pod.

This bug should be reproducible using LXD

1. Download GRUB and the shim. MAAS gets both from Bionic, you can download 
them direct here[1]
2. Setup a TFTP server to provide them
3. Add grub.cfg from MAAS[3]
4. Setup DHCP - Example dhcpd.conf from MAAS[4]
5. Create LXD VM
6. Modify LXD VM to boot from over the network
7. See boot failure

[1]http://paste.ubuntu.com/p/gjXhVTDgRv/
[2] https://images.maas.io/ephemeral-v3/daily/bootloaders/uefi/amd64/
[3] 
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template
[2] http://paste.ubuntu.com/p/RMRxYkDrNG/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1881821] Re: node inventory isn't being properly reported for Cisco UCS B200 M5 blade

2020-06-02 Thread Lee Trager
You can see from that output that link speed is being reported as 2
while interface speed is reported as 1. MAAS does not allow the link
speed to exceed the interface speed which causes the failure. Given that
both LXD and ethtool show the same data this seems to be a kernel bug.

** Changed in: maas
   Status: New => Triaged

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Summary changed:

- node inventory isn't being properly reported for Cisco UCS B200 M5 blade
+ Kernel does not report interface speed correctly for Cisco UCS B200 M5 blade

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881821

Title:
  Kernel does not report interface speed correctly for Cisco UCS B200 M5
  blade

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1881821/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-05-19 Thread Lee Trager
I tried modifying the MAAS local boot grub.cfg to directly chainboot
\efi\ubuntu\shimx64.efi. This gets rid of the failed to open/failed to
load errors. Local grub appears to load but halts saying the system is
compromised when it tries to boot the local kernel.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-05-19 Thread Lee Trager
MAAS doesn't know for sure what operating system is deployed locally.
When booting locally MAAS sends a grub.cfg[1] which searches for the
shim or local bootloader. MAAS first tries \efi\boot\bootx64.efi as that
is the default location as per the UEFI spec. Most operating systems
including Ubuntu put a bootloader there. The shim fails to find grub as
Ubuntu only stores grub in \efi\ubuntu\grubx64.efi. The two failure
messages are from that. The config then tries to load
\efi\ubuntu\shimx64.efi which succeeds but is unable to verify either
\efi\ubuntu\shimx64.efi or \efi\ubuntu\grubx64.efi.


[1] 
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-05-19 Thread Lee Trager
Based on the MAAS logs the halt happens after the remote shim, grub, and
grub.cfg have been loaded. I didn't see anything in the console to show
grub running but it may have been cleared before I could see it.

Console output:

Booting local disk...
Failed to open \efi\boot\grubx64.efi - Not Found
Failed to load image \efi\boot\grubx64.efi: Not Found
start_image() returned Not Found


Bootloader has not verified loaded image.
System is compromised.  halting.


rackd.log

2020-05-19 20:54:04 provisioningserver.rackdservices.tftp: [info] bootx64.efi 
requested by 10.0.0.117
2020-05-19 20:54:04 provisioningserver.rackdservices.tftp: [info] bootx64.efi 
requested by 10.0.0.117
2020-05-19 20:54:05 provisioningserver.rackdservices.tftp: [info] grubx64.efi 
requested by 10.0.0.117
2020-05-19 20:54:06 provisioningserver.rackdservices.tftp: [info] 
/grub/x86_64-efi/command.lst requested by 10.0.0.117
2020-05-19 20:54:06 provisioningserver.rackdservices.tftp: [info] 
/grub/x86_64-efi/fs.lst requested by 10.0.0.117
2020-05-19 20:54:06 provisioningserver.rackdservices.tftp: [info] 
/grub/x86_64-efi/crypto.lst requested by 10.0.0.117
2020-05-19 20:54:06 provisioningserver.rackdservices.tftp: [info] 
/grub/x86_64-efi/terminal.lst requested by 10.0.0.117
2020-05-19 20:54:06 provisioningserver.rackdservices.tftp: [info] 
/grub/grub.cfg requested by 10.0.0.117
2020-05-19 20:54:06 provisioningserver.rackdservices.tftp: [info] 
/grub/grub.cfg-00:16:3e:49:52:7b requested by 10.0.0.117


You can reproduce this pretty easily with MAAS 2.8 and LXD Pods.

1. Install MAAS 2.8
2. Add an LXD Pod
3. Compose a machine in the LXD Pod and let it commission
4. Reenable secure boot in the LXD virtual machine
   lxc config edit 
   Delete the line 'security.secureboot: "false"'
5. Attempt to deploy Ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-05-19 Thread Lee Trager
@Jeff MAAS uses the same bits as what the ISO uses. What is different is
how local booting happens with MAAS vs with the ISO. When installed with
the ISO the local boot process is UEFI Firmware -> Shim(from disk) ->
GRUB(from disk) -> Boot local kernel. When installed with MAAS the local
boot process is UEFI Firmware -> Shim(from network) -> GRUB(from
network) -> Shim(from disk) -> Grub(from disk) -> Boot local kernel. The
chain of trust when switching going from GRUB(from network) to Shim(from
disk). I suspect but haven't verified that this may be due to the shim
not being signed with a key GRUB has.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2020-05-18 Thread Lee Trager
I modified MAAS to only provide GRUB and skip the Shim. In that case
HTTP boot still doesn't work. It looks like when GRUB is loaded over
HTTP it does not bring up networking. I can still manually load
networking with net_dhcp and specify the remote grub.cfg file. GRUB does
download the kernel and initrd the remote grub.cfg file specifies but it
looks like it never actually excutes them.

** Summary changed:

- Shim does not hand off networking during HTTP boot
+ GRUB does not bring up networking when loaded over HTTP

** Description changed:

  When using MAAS to HTTP boot on x86_64 UEFI grub drops to the command
  line. net_ls_addr shows the system has no address. If I run net_dhcp I
  get an address. I can then download the remote grub.cfg file and
  continue boot.
  
  When reproducing with QEMU you have to manually reconfigure the boot
  order to try HTTP before TFTP:
  
  # efibootmgr -v
  BootCurrent: 0002
  Timeout: 0 seconds
  BootOrder: 0002,0003,0001,,0004
  Boot* UiApp   
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
  Boot0001* UEFI QEMU QEMU HARDDISK 
PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/SCSI(1,1)N.YMR,Y.
  Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)   
PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
  Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)  
PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.YMR,Y.
  Boot0004* EFI Internal Shell  
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
  # efibootmgr -o 0003,0002,0001,0004
  BootCurrent: 0002
  Timeout: 0 seconds
  BootOrder: 0003,0002,0001,0004
  Boot* UiApp
  Boot0001* UEFI QEMU QEMU HARDDISK
  Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)
  Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)
  Boot0004* EFI Internal Shell
  
  grub> net_ls_addr
  grub>
  grub> net_dhcp
  efinet0:dhcp 00:16:3e:03:be:1a 10.0.0.75
  grub> configfile (http,10.0.0.2:5248)/grub/grub.cfg-default-amd64
  Booting under MAAS direction...
  
  The kernel and initrd are downloaded but it hangs there.
  
- I believe the bug is in grub or the shim. As MAAS receives its
- bootloaders from the stream at images.maas.io generated by lp:maas-
- images this affects all versions of MAAS.
+ I believe the bug is in grub. As MAAS receives its bootloaders from the
+ stream at images.maas.io generated by lp:maas-images this affects all
+ versions of MAAS. Currently MAAS uses GRUB and the Shim from Bionic
+ however I have been able to reproduce this bug using GRUB and the shim
+ from Focal as well.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  GRUB does not bring up networking when loaded over HTTP

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879012] [NEW] Shim does not hand off networking during HTTP boot

2020-05-15 Thread Lee Trager
Public bug reported:

When using MAAS to HTTP boot on x86_64 UEFI grub drops to the command
line. net_ls_addr shows the system has no address. If I run net_dhcp I
get an address. I can then download the remote grub.cfg file and
continue boot.

When reproducing with QEMU you have to manually reconfigure the boot
order to try HTTP before TFTP:

# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0003,0001,,0004
Boot* UiApp 
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI QEMU QEMU HARDDISK   
PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/SCSI(1,1)N.YMR,Y.
Boot0002* UEFI PXEv4 (MAC:00163E03BE1A) 
PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)
PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.YMR,Y.
Boot0004* EFI Internal Shell
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
# efibootmgr -o 0003,0002,0001,0004
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0003,0002,0001,0004
Boot* UiApp
Boot0001* UEFI QEMU QEMU HARDDISK
Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)
Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)
Boot0004* EFI Internal Shell

grub> net_ls_addr
grub>
grub> net_dhcp
efinet0:dhcp 00:16:3e:03:be:1a 10.0.0.75
grub> configfile (http,10.0.0.2:5248)/grub/grub.cfg-default-amd64
Booting under MAAS direction...

The kernel and initrd are downloaded but it hangs there.

I believe the bug is in grub or the shim. As MAAS receives its
bootloaders from the stream at images.maas.io generated by lp:maas-
images this effects all versions of MAAS.

** Affects: maas
 Importance: High
 Status: Confirmed

** Affects: grub (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: shim-signed (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: shim-signed (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: grub (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  When using MAAS to HTTP boot on x86_64 UEFI grub drops to the command
  line. net_ls_addr shows the system has no address. If I run net_dhcp I
  get an address. I can then download the remote grub.cfg file and
  continue boot.
  
  When reproducing with QEMU you have to manually reconfigure the boot
  order to try HTTP before TFTP:
  
  # efibootmgr -v
  BootCurrent: 0002
  Timeout: 0 seconds
  BootOrder: 0002,0003,0001,,0004
  Boot* UiApp   
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
  Boot0001* UEFI QEMU QEMU HARDDISK 
PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/SCSI(1,1)N.YMR,Y.
  Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)   
PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)N.YMR,Y.
  Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)  
PciRoot(0x0)/Pci(0x4,0x0)/Pci(0x0,0x0)/MAC(00163e03be1a,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.YMR,Y.
  Boot0004* EFI Internal Shell  
FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
  # efibootmgr -o 0003,0002,0001,0004
  BootCurrent: 0002
  Timeout: 0 seconds
  BootOrder: 0003,0002,0001,0004
  Boot* UiApp
- Boot0001* UEFI QEMU QEMU HARDDISK 
+ Boot0001* UEFI QEMU QEMU HARDDISK
  Boot0002* UEFI PXEv4 (MAC:00163E03BE1A)
  Boot0003* UEFI HTTPv4 (MAC:00163E03BE1A)
  Boot0004* EFI Internal Shell
  
  grub> net_ls_addr
  grub>
  grub> net_dhcp
  efinet0:dhcp 00:16:3e:03:be:1a 10.0.0.75
  grub> configfile (http,10.0.0.2:5248)/grub/grub.cfg-default-amd64
  Booting under MAAS direction...
  
+ The kernel and initrd are downloaded but it hangs there.
+ 
  I believe the bug is in grub or the shim. As MAAS receives its
  bootloaders from the stream at images.maas.io generated by lp:maas-
  images this effects all versions of MAAS.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012

Title:
  Shim does not hand off networking during HTTP boot

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1879012/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust

2020-05-15 Thread Lee Trager
For LXD Pods[1] we had to disable secure boot to get around this issue.
When this bug is fixed we should reenable secure boot for LXD Pods.

[1]
https://git.launchpad.net/maas/tree/src/provisioningserver/drivers/pod/lxd.py#n515

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1865515] Re: MAAS can't deploy to a server with Secure Boot active

2020-05-15 Thread Lee Trager
This isn't a bug with MAAS, it's a bug with shim/grub. MAAS gets its
bootloaders from the public stream at images.maas.io which is generated
by lp:maas-images. lp:maas-images pulls the bootloaders out of the
archive, its currently set to pull them from bionic.

Secure boot is working in the ephemeral environment it's failing when
trying to local boot into the deployed environment. When an x86_64 UEFI
machine local boots with MAAS it boots over the network, downloads
bootx64.efi(shim) which downloads grubx64.efi and this grub.cfg[1]. The
grub from over the network finds /boot/efi/ubuntu/shimx64.efi on the
local filesystem and chainboots to it. Somehow the chain of trust breaks
here causing the system to halt.

Booting local disk...
Failed to open \efi\boot\grubx64.efi - Not Found
Failed to load image \efi\boot\grubx64.efi: Not Found
start_image() returned Not Found
EFI stub: UEFI Secure Boot is enabled.
Bootloader has not verified loaded image.
System is compromised.  halting.

I tried using the shim and grub from Focal but I still get the same
problem.

[1]
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template

** Also affects: shim-signed (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: grub (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: grub (Ubuntu)
   Status: New => Confirmed

** Changed in: shim-signed (Ubuntu)
   Status: New => Confirmed

** Summary changed:

- MAAS can't deploy to a server with Secure Boot active
+ Chainbooting from grub over the network to local shim breaks chain of trust

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515

Title:
  Chainbooting from grub over the network to local shim breaks chain of
  trust

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1865515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1867387] Re: \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

2020-05-15 Thread Lee Trager
*** This bug is a duplicate of bug 1865515 ***
https://bugs.launchpad.net/bugs/1865515

** This bug has been marked a duplicate of bug 1865515
   Chainbooting from grub over the network to local shim breaks chain of trust

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867387

Title:
  \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1867387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1867387] Re: \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

2020-05-01 Thread Lee Trager
shim-signed from Focal does not fix the issue.

** Changed in: shim-signed (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867387

Title:
  \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1867387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1872021] Re: commissioning fails due to hung tasks setting up ipmitool

2020-04-17 Thread Lee Trager
MAAS instructs cloud-init to install ipmitool during commissioning. If
you select "Skip configuring supported BMC controllers with a MAAS
generated username and password" and "Allow SSH access and prevent
machine powering off" ipmitool won't be installed and the machine will
be left on after commissioning/testing to allow for debug. You can also
boot into rescue mode on a failed host.

** Changed in: ipmitool (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872021

Title:
  commissioning fails due to hung tasks setting up ipmitool

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1872021/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1872124] Re: Please integrate ubuntu-drivers --gpgpu into Ubuntu Server

2020-04-15 Thread Lee Trager
MAAS contains a way to automatically install drivers. Every region has a
file, /etc/maas/drivers.yaml, which specifies drivers which should be
automatically installed. I don't have access to any test hardware but I
*think* this should work. One thing I noticed is there isn't a meta
package for the nVidia driver which points to the latest version for
each Ubuntu release. We would need that before adding this to MAAS.

diff --git a/drivers-orig.yaml b/drivers.yaml
index 2d3724c..97a4eb2 100644
--- a/drivers-orig.yaml
+++ b/drivers.yaml
@@ -82,3 +82,10 @@ drivers:
   repository: http://downloads.linux.hpe.com/SDR/repo/ubuntu-hpdsa
   series:
 - trusty
+- blacklist: nouveau
+  comment: nVidia driver
+  modaliases:
+  - 'pci:v10DEd*sv*sd*bc03sc02i00*'
+  - 'pci:v10DEd*sv*sd*bc03sc00i00*'
+  - module: nvidia
+  - package: nvidia-headless-440

** Changed in: maas
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872124

Title:
  Please integrate ubuntu-drivers --gpgpu into Ubuntu Server

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1872124/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1872021] Re: commissioning fails due to hung tasks setting up ipmitool

2020-04-10 Thread Lee Trager
** Also affects: linux
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872021

Title:
  commissioning fails due to hung tasks setting up ipmitool

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1872021/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1871963] Re: dpkg fails to install grub-efi-amd64 signed and shim-signed

2020-04-09 Thread Lee Trager
It looks like there is an extra ';;' in the script, the following patch
fixes it.

--- /tmp/grub-efi-amd64-signed.postinst 2020-04-09 16:50:58.585757438 -0700
+++ /var/lib/dpkg/info/grub-efi-amd64-signed.postinst   2020-04-09 
16:51:12.029644653 -0700
@@ -16,7 +16,7 @@
 
 case $1 in
 configure)
-   target=x86_64-efi
+   target=x86_64-efi ;;
# Check /boot/grub to see if we previously installed to an ESP. We don't
# want to trigger the install code just by installing the package,
# normally the installer installs grub itself first.

I do get a warning that "The GRUB boot loader was previously installed
to a disk that is no longer present, or whose unique identifier has
changed for some reason." I haven't changed the disks on my system or
done anything else that should trigger this.

** Also affects: grub (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: grub (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871963

Title:
  dpkg fails to install grub-efi-amd64 signed and shim-signed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1871963/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1871963] Re: dpkg fails to install grub-efi-amd64 signed and shim-signed

2020-04-09 Thread Lee Trager
Just confirming this as well

 sudo apt install -f
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up grub-efi-amd64-signed (1.139+2.04-1ubuntu24) ...
/var/lib/dpkg/info/grub-efi-amd64-signed.postinst: 23: Syntax error: word 
unexpected (expecting ")")
dpkg: error processing package grub-efi-amd64-signed (--configure):
 installed grub-efi-amd64-signed package post-installation script subprocess 
returned error exit status
 2
Errors were encountered while processing:
 grub-efi-amd64-signed
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871963

Title:
  dpkg fails to install grub-efi-amd64 signed and shim-signed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1871963/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Re: Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

2020-03-30 Thread Lee Trager
I tested booting into Bionic which showed the battery level working.
When I booted back into Focal the battery level was working again. I'm
not sure why that fixed it but it did.

Thanks for looking into this!

** Changed in: linux (Ubuntu)
   Status: Confirmed => Invalid

** Tags removed: champagne

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1869116] Re: smartctl-validate is borked in a recent release

2020-03-30 Thread Lee Trager
That makes sense based on the other information in this bug.

MAAS sends the test runner a list of storage devices to run hardware
tests on. The test runner uses the model and serial to map to a block
device name. This block device name is passed to the smartctl-validate
script. smartctl-validate uses smartctl to determine if SMART data is
available for the device.

Because the model name differs between lsblk and lxc it can't be looked
up and the test is marked as a failure. The mapping needs to work so
MAAS can pass the block device to to smartctl-validate which knows the
test can be skipped.

** Tags added: champagne

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116

Title:
  smartctl-validate is borked in a recent release

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxd/+bug/1869116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1868915] Re: [focal] nm-online -s --timeout=10 timeout every time

2020-03-30 Thread Lee Trager
NetworkManager isn't installed in the base MAAS Focal image.

Are you using the default image from images.maas.io?

What cloud-init user-data are you sending to the install?

Have you modified the preseed file at all?

** Changed in: maas
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868915

Title:
  [focal] nm-online -s --timeout=10 timeout every time

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1868915/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1869116] Re: smartctl-validate is borked in a recent release

2020-03-27 Thread Lee Trager
I spoke with the LXD team and they're passing through the name they get
from the kernel. It seems like this may be a bug that was introduced to
util-linux with RAID devices. I tried running lsblk on Focal against two
NVME drives and I do not see an underscore used in model names.

@cees - Can you try using a different commissioning operating system and
see if the problem is resolved? You can download 16.04 and 20.04 on the
images page and then change the commissioning operating system on the
settings page.

** Also affects: util-linux-ng
   Importance: Undecided
   Status: New

** No longer affects: util-linux-ng

** Also affects: util-linux (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116

Title:
  smartctl-validate is borked in a recent release

To manage notifications about this bug go to:
https://bugs.launchpad.net/lxd/+bug/1869116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1867935] Re: remove openwsman and rdep wsmancli

2020-03-23 Thread Lee Trager
MAAS uses wsmancli for AMT support which is required by Intel NUCs.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867935

Title:
  remove openwsman and rdep wsmancli

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1867935/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1867387] Re: \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

2020-03-13 Thread Lee Trager
On both the ISO install and MAAS install
/boot/efi/EFI/ubuntu/BOOTX64.CSV contains

shimx64.efi,ubuntu,,This is the boot entry for ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867387

Title:
  \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1867387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1867387] Re: \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

2020-03-13 Thread Lee Trager
\EFI\BOOT\BOOTX64.EFI is always installed on an Ubuntu system be it MAAS
or ISO.

Focal install via ISO from December 2019
# tree /boot/efi/
/boot/efi/
└── EFI
├── BOOT
│   ├── BOOTX64.EFI
│   ├── fbx64.efi
│   └── mmx64.efi
└── ubuntu
├── BOOTX64.CSV
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi

3 directories, 8 files

Bionic install via MAAS today
# tree /boot/efi/
/boot/efi/
└── EFI
├── BOOT
│   ├── BOOTX64.EFI
│   └── fbx64.efi
└── ubuntu
├── BOOTX64.CSV
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi

3 directories, 7 files

** Changed in: shim-signed (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867387

Title:
  \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1867387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1867387] [NEW] \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

2020-03-13 Thread Lee Trager
Public bug reported:

Machines managed by MAAS are configured to always netboot. When an
operating system is deployed MAAS chainloads the local boot loader[1].
As per the 3.5.1.1 of UEFI spec[2] \EFI\BOOT\BOOTX64.EFI is attempted
first. \EFI\BOOT\BOOTX64.EFI fails to find GRUBX64.efi as it is located
in \EFI\UBUNTU(see screenshot).

[1] 
https://git.launchpad.net/maas/tree/src/provisioningserver/templates/uefi/config.local.amd64.template
[2] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf

** Affects: shim-signed (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: "uefi-failure.png"
   
https://bugs.launchpad.net/bugs/1867387/+attachment/5336609/+files/uefi-failure.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867387

Title:
  \EFI\BOOT\BOOTX64.EFI unable to find GRUBX64.EFI

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1867387/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1862846] Re: Crash and failure installing focal

2020-02-19 Thread Lee Trager
Ryan has updated Curtin to no longer require that util-linux feature. I
do think it would be good to carry that patch in Ubuntu as it other
users will be effected by that regression.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862846

Title:
  Crash and failure installing focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1862846] Re: Crash and failure installing focal

2020-02-12 Thread Lee Trager
** Bug watch added: Debian Bug tracker #951217
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951217

** Also affects: util-linux (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951217
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862846

Title:
  Crash and failure installing focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1862846] Re: Crash and failure installing focal

2020-02-11 Thread Lee Trager
Upstream util-linux has fixed this in 2.34.1+

https://github.com/karelzak/util-linux/issues/813

** Bug watch added: github.com/karelzak/util-linux/issues #813
   https://github.com/karelzak/util-linux/issues/813

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862846

Title:
  Crash and failure installing focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1862846] Re: Crash and failure installing focal

2020-02-11 Thread Lee Trager
I agree a -b or -e should be used instead of -f. However pkname is a
valid column in lsblk. From lsblk --help:

KNAME  internal kernel device name
PKNAME  internal parent kernel device name

pkname not working is a regression which was introduced in util-
linux-2.34[1]. Upstream has fixed this[2].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1751290
[2] 
https://github.com/karelzak/util-linux/commit/e3bb9bfb76c17b1d05814436ced62c05c4011f48

** Bug watch added: Red Hat Bugzilla #1751290
   https://bugzilla.redhat.com/show_bug.cgi?id=1751290

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1862846

Title:
  Crash and failure installing focal

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Re: Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

2020-02-09 Thread Lee Trager
** Tags added: champagne

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Re: Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

2020-02-09 Thread Lee Trager
I've only ever run Focal on this laptop. When I first installed(end of
December 2019) the battery level worked. I was using it while plugged in
for a few weeks and recently noticed that the battery level stopped
working.

According to [1] this laptop is certified pre-install for Ubuntu.

[1] https://certification.ubuntu.com/hardware/201906-27150

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Re: Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

2020-01-30 Thread Lee Trager
** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861332] Re: Bump version to 1.90 to add support for Synaptics 06cb:00bd

2020-01-29 Thread Lee Trager
** Summary changed:

- Bump version to 2.x to add support for Synaptics 06cb:00bd
+ Bump version to 1.90 to add support for Synaptics 06cb:00bd

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861332

Title:
  Bump version to 1.90 to add support for Synaptics 06cb:00bd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libfprint/+bug/1861332/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] RfKill.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "RfKill.txt"
   https://bugs.launchpad.net/bugs/1861330/+attachment/5323902/+files/RfKill.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] PulseList.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "PulseList.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323901/+files/PulseList.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] UdevDb.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "UdevDb.txt"
   https://bugs.launchpad.net/bugs/1861330/+attachment/5323903/+files/UdevDb.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] ProcInterrupts.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "ProcInterrupts.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323899/+files/ProcInterrupts.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] CRDA.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "CRDA.txt"
   https://bugs.launchpad.net/bugs/1861330/+attachment/5323890/+files/CRDA.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] ProcModules.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "ProcModules.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323900/+files/ProcModules.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] CurrentDmesg.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "CurrentDmesg.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323891/+files/CurrentDmesg.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] ProcCpuinfoMinimal.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "ProcCpuinfoMinimal.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323898/+files/ProcCpuinfoMinimal.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Re: Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

2020-01-29 Thread Lee Trager
apport information

** Tags added: apport-collected focal

** Description changed:

  I have a Lenovo X1 Carbon Extreme Gen 2. When I first installed Focal on
  it battery status was working however its now stuck at 59% even though
  its been charging for days.
  
  $ cat /sys/class/power_supply/BAT0/status
  Unknown
  $ cat /sys/class/power_supply/BAT0/capacity
  59
+ --- 
+ ProblemType: Bug
+ ApportVersion: 2.20.11-0ubuntu15
+ Architecture: amd64
+ AudioDevicesInUse:
+  USERPID ACCESS COMMAND
+  /dev/snd/controlC2:  lee4054 F pulseaudio
+  /dev/snd/controlC1:  lee4054 F pulseaudio
+  /dev/snd/controlC0:  lee4054 F pulseaudio
+  /dev/snd/pcmC0D0p:   lee4054 F...m pulseaudio
+ CurrentDesktop: ubuntu:GNOME
+ DistroRelease: Ubuntu 20.04
+ InstallationDate: Installed on 2019-12-29 (31 days ago)
+ InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191220)
+ MachineType: LENOVO 20QVCTO1WW
+ NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset 
nvidia
+ Package: linux (not installed)
+ ProcEnviron:
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
+ ProcFB: 0 i915drmfb
+ ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-12-generic 
root=/dev/mapper/samsung--ssd-ROOT ro quiet splash vt.handoff=7
+ ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8
+ RelatedPackageVersions:
+  linux-restricted-modules-5.4.0-12-generic N/A
+  linux-backports-modules-5.4.0-12-generic  N/A
+  linux-firmware1.185
+ Tags:  focal
+ Uname: Linux 5.4.0-12-generic x86_64
+ UpgradeStatus: No upgrade log present (probably fresh install)
+ UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo 
wireshark
+ _MarkForUpload: True
+ dmi.bios.date: 11/25/2019
+ dmi.bios.vendor: LENOVO
+ dmi.bios.version: N2OET41W (1.28 )
+ dmi.board.asset.tag: Not Available
+ dmi.board.name: 20QVCTO1WW
+ dmi.board.vendor: LENOVO
+ dmi.board.version: SDK0R32862 WIN
+ dmi.chassis.asset.tag: No Asset Information
+ dmi.chassis.type: 10
+ dmi.chassis.vendor: LENOVO
+ dmi.chassis.version: None
+ dmi.modalias: 
dmi:bvnLENOVO:bvrN2OET41W(1.28):bd11/25/2019:svnLENOVO:pn20QVCTO1WW:pvrThinkPadX1Extreme2nd:rvnLENOVO:rn20QVCTO1WW:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrNone:
+ dmi.product.family: ThinkPad X1 Extreme 2nd
+ dmi.product.name: 20QVCTO1WW
+ dmi.product.sku: LENOVO_MT_20QV_BU_Think_FM_ThinkPad X1 Extreme 2nd
+ dmi.product.version: ThinkPad X1 Extreme 2nd
+ dmi.sys.vendor: LENOVO

** Attachment added: "AlsaInfo.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323889/+files/AlsaInfo.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Lsusb-t.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "Lsusb-t.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323895/+files/Lsusb-t.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] Lspci.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "Lspci.txt"
   https://bugs.launchpad.net/bugs/1861330/+attachment/5323893/+files/Lspci.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1861330] IwConfig.txt

2020-01-29 Thread Lee Trager
apport information

** Attachment added: "IwConfig.txt"
   
https://bugs.launchpad.net/bugs/1861330/+attachment/5323892/+files/IwConfig.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330

Title:
  Battery status unknown on Lenovo X1 Carbon Extreme Gen 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1861330/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

  1   2   3   >