[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: /org/freedesktop/UPower/devices/line_power_u
[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 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] 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 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
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
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
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 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 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 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 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 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 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 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 1789319] Re: Unable to load shimx64.efi using iPXE over UEFI
Isn't iPXE what implements TFTP PXE boot? When I tried Julian's command kvm tries UEFI HTTP boot which isn't currently implemented in MAAS and is blocked by lack of grub support(LP:1787630). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1789319 Title: Unable to load shimx64.efi using iPXE over UEFI To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1789319/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1797235] [NEW] Xorg crashes when using nvidia-driver-390 with secure boot disabled
Public bug reported: The latest nvidia update causes X.org to crash as soon as I try to login with gdm. I can login to Wayland for a few minutes but it then crashes as well. While going through dmesg I saw the following. It appears that the crash is happening because I disabled UEFI secure boot. Once I reenabled it the system become stable and I can now use X.org or Wayland. Oct 10 13:48:49 ltrager-laptop kernel: PKCS#7 signature not signed with a trusted key Oct 10 13:48:49 ltrager-laptop kernel: nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.77 Tue Jul 10 22:10:46 PDT 2018 Oct 10 13:48:49 ltrager-laptop kernel: PKCS#7 signature not signed with a trusted key Oct 10 13:48:49 ltrager-laptop kernel: [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver Oct 10 13:48:49 ltrager-laptop kernel: [drm] Initialized nvidia-drm 0.0.0 20160202 for :01:00.0 on minor 0 Oct 10 13:48:49 ltrager-laptop kernel: PKCS#7 signature not signed with a trusted key Oct 10 13:48:49 ltrager-laptop kernel: nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 239 Oct 10 13:48:49 ltrager-laptop systemd-udevd[4290]: Process '/sbin/create-uvm-dev-node' failed with exit code 1. ** Affects: nvidia-graphics-drivers-390 (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/1797235 Title: Xorg crashes when using nvidia-driver-390 with secure boot disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-390/+bug/1797235/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800153] Re: [2.5] Failed to deploy ppc64el when partition table is GPT
Every time I commission the PPC host we have in our CI I always get a GPT partitioning table using MAAS 2.4.2+. Looking through the source code it appears GPT is always set when creating a new partitioning table[1] and when generating the preseed[2] due to the bios_boot_method being powernv. I'm not sure how msdos got set but I believe the partition table type is a red herring. The issue appears to be that Curtin is not wiping the PReP partition(/dev/sda1). If I chroot into the deployment environment and try to install GRUB with grub-install --target=powerpc-ieee1275 /dev/sda1 --no-nvram it fails. If I wipe /dev/sda1 first GRUB installation succeeds. I can then retry deployment and deployment works fine. I suspect the issue has to do with a newer version of GRUB being installed. Previous versions of GRUB must of been similar enough that the PReP partition didn't have to be fully wiped before installing. @Ryan, as you mentioned Curtin has a bug where it is not fully wiping the PReP partition which appears to be the root cause of this bug. It may be worth modifying Curtin to always wipe any partition with the 'prep' flag set regardless of what wipe is set to to ensure this doesn't happen in other environments. [1] https://git.launchpad.net/maas/tree/src/maasserver/models/partitiontable.py#n152 [2] https://git.launchpad.net/maas/tree/src/maasserver/preseed_storage.py#n254 ** Changed in: curtin Status: Incomplete => Confirmed ** Changed in: grub2 (Ubuntu) Status: New => Invalid ** Changed in: maas Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800153 Title: [2.5] Failed to deploy ppc64el when partition table is GPT To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1800153/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1792575] Re: Boot failure with efi shims from 20180913.0
I'm also unable to verify the fix using the MAAS CI. However I did confirm the new shim works. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1792575 Title: Boot failure with efi shims from 20180913.0 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1792575/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800153] Re: [2.5] Failed to deploy ppc64el when partition table is GPT
** No longer affects: maas -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800153 Title: [2.5] Failed to deploy ppc64el when partition table is GPT To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1800153/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800153] Re: [2.5] Failed to deploy ppc64el when partition table is GPT
My theory on different versions of GRUB causing the issue didn't pan out. After wiping the PReP partition I was able to go between 14.04, 16.04, and 18.04 with no problems. The only way I've been able to reproduce the issue after fixing it is by filling the PReP partition with garbage using $ dd if=/dev/urandom of=/dev/sda1 This may of happened in our CI by running a destructive storage test (badblock-destructive, fio). @Scott MAAS is already telling Curtin to wipe the PReP partition, Curtin isn't fully wiping it which is why we're seeing the problem. I was merely suggesting wiping PReP by default may be useful in non-MAAS environments to prevent this error. I see why you wouldn't want to do that so feel free to ignore my suggestion :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800153 Title: [2.5] Failed to deploy ppc64el when partition table is GPT To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1800153/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1801899] Re: cannot install with python3.7 as default async is a reserved keyword
** Changed in: maas Importance: Undecided => Critical ** Changed in: maas 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/1801899 Title: cannot install with python3.7 as default async is a reserved keyword To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1801899/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1789319] Re: Unable to load shimx64.efi using iPXE over UEFI
I've verified that the updated ipxe package fixes virsh UEFI deployments wtih MAAS. I tested commissioning, and deploying both Ubuntu 18.04 and CentOS 7. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1789319 Title: Unable to load shimx64.efi using iPXE over UEFI To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1789319/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813227] Re: lvm2-pvscan services fails to start on S390X DPM
I tested a Disco image today with multipath-tools installed and I still get the same thing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813227 Title: lvm2-pvscan services fails to start on S390X DPM To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1813227/+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 1646805] Re: MAC address needs to be unique and unchanged during entire netboot process
I tested this today using 5.0.0-8-generic and between reboots I am still getting different MAC addresses on Z13. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1646805 Title: MAC address needs to be unique and unchanged during entire netboot process To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1646805/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813227] Re: lvm2-pvscan services fails to start on S390X DPM
** Attachment added: "lsblk output" https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1813227/+attachment/5233345/+files/lsblk.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813227 Title: lvm2-pvscan services fails to start on S390X DPM To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1813227/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1813227] Re: lvm2-pvscan services fails to start on S390X DPM
The MAAS ephemeral environment does not have the multipath kernel module nor multipath-tools. To get this log I had to install both. ** Attachment added: "multipath.log" https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1813227/+attachment/5233346/+files/multipath.log -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1813227 Title: lvm2-pvscan services fails to start on S390X DPM To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1813227/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1861330] [NEW] Battery status unknown on Lenovo X1 Carbon Extreme Gen 2
Public bug reported: 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 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete -- 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] [NEW] Bump version to 2.x to add support for Synaptics 06cb:00bd
Public bug reported: I recently bought a Lenovo X1 Carbon Extreme Gen 2 which comes with a Synaptics fingerprint reader(06cb:00bd). fprintd has been patched to add support for this fingerprint reader[1] which was released in 1.90[2]. Focal currently has fprintd 0.9. [1] https://gitlab.freedesktop.org/libfprint/libfprint/issues/181 [2] https://gitlab.freedesktop.org/libfprint/libfprint/-/tags/V_1_90_0 ** Affects: libfprint (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/1861332 Title: Bump version to 2.x 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] Lsusb.txt
apport information ** Attachment added: "Lsusb.txt" https://bugs.launchpad.net/bugs/1861330/+attachment/5323894/+files/Lsusb.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-v.txt
apport information ** Attachment added: "Lsusb-v.txt" https://bugs.launchpad.net/bugs/1861330/+attachment/5323896/+files/Lsusb-v.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] ProcCpuinfo.txt
apport information ** Attachment added: "ProcCpuinfo.txt" https://bugs.launchpad.net/bugs/1861330/+attachment/5323897/+files/ProcCpuinfo.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
[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] 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] 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] 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 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] 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 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 1859751] [NEW] Piston missing support for Django 2.2
Public bug reported:
Focal has upgraded Django to 2.2. Piston requires changes to work with
the newer version of Django. This breaks MAAS on Focal/base 20.04.
Traceback (most recent call last):
File "/usr/bin/maas", line 11, in
load_entry_point('maas==2.7.0rc1', 'console_scripts', 'maas')()
File "/usr/lib/python3/dist-packages/maascli/__init__.py", line 39, in main
parser = prepare_parser(argv)
File "/usr/lib/python3/dist-packages/maascli/parser.py", line 71, in
prepare_parser
register_cli_commands(parser)
File "/usr/lib/python3/dist-packages/maascli/cli.py", line 283, in
register_cli_commands
django_setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in
populate
app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in
import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 967, in _find_and_load_unlocked
File "", line 677, in _load_unlocked
File "", line 728, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/maasserver/models/__init__.py", line 99,
in
from piston3.doc import HandlerDocumentation
File "/usr/lib/python3/dist-packages/piston3/doc.py", line 3, in
from . import handler
File "/usr/lib/python3/dist-packages/piston3/handler.py", line 5, in
from .utils import rc
File "/usr/lib/python3/dist-packages/piston3/utils.py", line 8, in
from django.core.urlresolvers import reverse
ModuleNotFoundError: No module named 'django.core.urlresolvers'
Traceback (most recent call last):
File "/usr/bin/maas", line 11, in
load_entry_point('maas==2.7.0rc1', 'console_scripts', 'maas')()
File "/usr/lib/python3/dist-packages/maascli/__init__.py", line 39, in main
parser = prepare_parser(argv)
File "/usr/lib/python3/dist-packages/maascli/parser.py", line 71, in
prepare_parser
register_cli_commands(parser)
File "/usr/lib/python3/dist-packages/maascli/cli.py", line 283, in
register_cli_commands
django_setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in
populate
app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in
import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 967, in _find_and_load_unlocked
File "", line 677, in _load_unlocked
File "", line 728, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/maasserver/models/__init__.py", line 99,
in
from piston3.doc import HandlerDocumentation
File "/usr/lib/python3/dist-packages/piston3/doc.py", line 3, in
from . import handler
File "/usr/lib/python3/dist-packages/piston3/handler.py", line 5, in
from .utils import rc
File "/usr/lib/python3/dist-packages/piston3/utils.py", line 8, in
from django.core.urlresolvers import reverse
ModuleNotFoundError: No module named 'django.core.urlresolvers'
Traceback (most recent call last):
File "/usr/bin/maas", line 11, in
load_entry_point('maas==2.7.0rc1', 'console_scripts', 'maas')()
File "/usr/lib/python3/dist-packages/maascli/__init__.py", line 39, in main
parser = prepare_parser(argv)
File "/usr/lib/python3/dist-packages/maascli/parser.py", line 71, in
prepare_parser
register_cli_commands(parser)
File "/usr/lib/python3/dist-packages/maascli/cli.py", line 283, in
register_cli_commands
django_setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in
populate
app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in
import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1006, in _gcd_import
File "", line 983, in _find_and_load
File "", line 967, in _find_and_load_unlocked
File "", line 677, in _load_unlocked
File "", line 728, in exec_module
File "", line 219, in _call_with_frames_removed
File "/usr/lib/python3/
[Bug 1859751] Re: Piston missing support for Django 2.2
I marked it as critical because MAAS 2.6.0 is in Focal main. https://packages.ubuntu.com/focal/maas -- 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 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 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 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 1711203] Re: Deployments fail when Secure Boot enabled
While reading through #1730493 and #1437024 I noticed both had various UEFI bootloader issues fixed by switching to the Artful version of grub and the shim. I've updated http://162.213.35.187/proposed/streams/v1/index.json to use boot loaders from Artful in case anyone wants to test. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1711203 Title: Deployments fail when Secure Boot enabled To manage notifications about this bug go to: https://bugs.launchpad.net/curtin/+bug/1711203/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846535] Re: cloud-init 19.2.36 fails with python exception "Not all expected physical devices present ..." during bionic image deployment from MAAS
I manually tested the new cloud-init using the MAAS CI as we don't have automated tests for bonds or bridges. Xenial, Bionic, and Disco can all commissioning and deploy fine using static IPs, bonds, and bridges. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846535 Title: cloud-init 19.2.36 fails with python exception "Not all expected physical devices present ..." during bionic image deployment from MAAS To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1846535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1829945] Re: SDL support missing from qemu-1:3.1+dfsg-2ubuntu3.1
Thanks for the explanation. MAAS is starting to use Packer to create custom images so we may be packaging this soon. I will filed an upstream bug[1] and created a patch[2] to fix the issue. [1] https://github.com/hashicorp/packer/issues/7675 [2] https://github.com/hashicorp/packer/pull/7676 ** Bug watch added: github.com/hashicorp/packer/issues #7675 https://github.com/hashicorp/packer/issues/7675 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1829945 Title: SDL support missing from qemu-1:3.1+dfsg-2ubuntu3.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1829945/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1831134] Re: Pods Cannot allocate memory, even with memory_over_commit_ratio set 10.0
It appears your system is over committed to much. qemu needs a minimal amount of resources to be able to start the VM. Leaving this open as our docs and the UI should explain this better. ** Tags added: docs ui ** Changed in: maas Status: New => Triaged ** Changed in: maas Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1831134 Title: Pods Cannot allocate memory, even with memory_over_commit_ratio set 10.0 To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1831134/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1844334] Re: SRU cloud-init (19.2.36): Xenial, Bionic, and Disco
We're currently working on fixing the MAAS CI. In the meantime I was able to manually test Xenial, Bionic, and Disco with proposed. All were able to commission and deploy. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1844334 Title: SRU cloud-init (19.2.36): Xenial, Bionic, and Disco To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1844334/+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.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 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 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 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 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 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 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] 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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
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 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
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 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 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 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: 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 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 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
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 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 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 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 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 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 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
