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
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
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
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.
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
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
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.
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
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.
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
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
** 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
** 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,
ged 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
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
@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
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,
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
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
** 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.
** 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.
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
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
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
** 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
** 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
** 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
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
** 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
** 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
** 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
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3
** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012
Title:
GRUB does not bring up
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3
** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258
Title:
ubuntu 20.04 pxe
** Changed in: maas
Milestone: 2.9.0b2 => 2.9.0b3
** Changed in: maas
Milestone: 2.9.0b3 => 2.9.0b4
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over
I mean the output of /sys/class/dmi/id/product_uuid. However I'm not
sure how reliable that is. Since I made that comment we've had multiple
users report(LP:1893690) some vendors are handing out duplicate UUIDs.
MAAS handles this by ignoring any UUID which has been duplicated.
--
You received
MAAS tries to do
(FW) -> shim(net) -> grub(net) -> shim(local) -> grub(local)
When grub(net) runs MAAS send it this[1] config which searches for the
local bootloader as we don't know where it is. It prefers chainloading
the shim but will fall back on grub if that isn't found.
The reason we
SolutionsQA and the MAAS CI verify that operations like commissioning
and deploying work. AFAIK neither verify the deployed environment, just
that the CI can SSH into it. Since both CIs verify that MAAS doesn't go
down while testing this test case isn't hit.
I'll leave this open for MAAS to add
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879012
Title:
GRUB does not bring up networking when loaded over HTTP
To manage notifications
** Changed in: maas
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1859751
Title:
Piston missing support for Django 2.2
To manage notifications about
** Changed in: maas
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1881821
Title:
MAAS does not properly detect max interface speed for interfaces which
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876258
Title:
ubuntu 20.04 pxe installation fails with no such file or directory
** Changed in: maas
Milestone: 2.9.0b1 => 2.9.0b2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865515
Title:
Chainbooting from grub over the network to local shim breaks chain of
trust
To
** Changed in: maas
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1891331
Title:
ipmi-config command not found in snap
To manage notifications about
** Changed in: maas
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1892032
Title:
RM djorm-ext-pgarray, not needed since django 1.8 has it all
To manage
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 =>
** No longer affects: util-linux (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1869116
Title:
smartctl-validate is borked in a recent release
To manage notifications about this bug go to:
** Also affects: maas/2.7
Importance: Undecided
Status: New
** Changed in: maas/2.7
Importance: Undecided => Critical
** Changed in: maas/2.7
Assignee: (unassigned) => Lee Trager (ltrager)
--
You received this bug notification because you are a member of Ubuntu
Bugs,
* Changed in: maas/2.8
Importance: Undecided => High
** Changed in: maas
Importance: High => Critical
** Changed in: maas/2.8
Importance: High => Critical
** Changed in: maas
Milestone: None => 2.9.0b1
** Changed in: maas
Assignee: (unassigned) => Lee Trager (ltrager)
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
> 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
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
** 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
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
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
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
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.
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.
**
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
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
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
@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
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
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
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
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
*** 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
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:
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
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
** 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
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
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
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:
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
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
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
MAAS uses wsmancli for AMT support which is required by Intel NUCs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867935
Title:
remove openwsman and rdep wsmancli
To manage notifications about
On both the ISO install and MAAS install
/boot/efi/EFI/ubuntu/BOOTX64.CSV contains
shimx64.efi,ubuntu,,This is the boot entry for ubuntu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867387
Title:
\EFI\BOOT\BOOTX64.EFI is always installed on an Ubuntu system be it MAAS
or ISO.
Focal install via ISO from December 2019
# tree /boot/efi/
/boot/efi/
└── EFI
├── BOOT
│ ├── BOOTX64.EFI
│ ├── fbx64.efi
│ └── mmx64.efi
└── ubuntu
├── BOOTX64.CSV
├──
Public bug reported:
Machines managed by MAAS are configured to always netboot. When an
operating system is deployed MAAS chainloads the local boot loader[1].
As per the 3.5.1.1 of UEFI spec[2] \EFI\BOOT\BOOTX64.EFI is attempted
first. \EFI\BOOT\BOOTX64.EFI fails to find GRUBX64.efi as it is
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.
** Bug watch added: Debian Bug tracker #951217
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951217
** Also affects: util-linux (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951217
Importance: Unknown
Status: Unknown
--
You received this bug notification
Upstream util-linux has fixed this in 2.34.1+
https://github.com/karelzak/util-linux/issues/813
** Bug watch added: github.com/karelzak/util-linux/issues #813
https://github.com/karelzak/util-linux/issues/813
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I agree a -b or -e should be used instead of -f. However pkname is a
valid column in lsblk. From lsblk --help:
KNAME internal kernel device name
PKNAME internal parent kernel device name
pkname not working is a regression which was introduced in util-
linux-2.34[1]. Upstream has fixed this[2].
** Tags added: champagne
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1861330
Title:
Battery status unknown on Lenovo X1 Carbon Extreme Gen 2
To manage notifications about this bug go to:
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]
** 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
** 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
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:
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
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:
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.
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:
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
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.
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.
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
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:
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:
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
1 - 100 of 207 matches
Mail list logo
