[Bug 1865515] Re: Chainbooting from grub over the network to local shim breaks chain of trust
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
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
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
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
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
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
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
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
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
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
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
** 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
** 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
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
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
@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
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
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
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
** 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
** 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
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
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
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
** 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
** 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
** 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
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
** 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
** 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
** 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
** 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
** 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
** 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
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
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
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
** 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
** 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)
** 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
** 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
** 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
** 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
** 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
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
** 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
** 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
** 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
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
> 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
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)
** 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
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
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
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
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
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
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
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
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
@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
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
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
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
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
*** 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
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
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
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
** 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
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
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
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
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
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
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
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
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
\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
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
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
** 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
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
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
** 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
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
** 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
** 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
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
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
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
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
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
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
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
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
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
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
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
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