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
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 ex
** 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. Th
** 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. Th
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
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 gru
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.
h
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 upda
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 'se
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-
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 loc
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://
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 su
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. Ma
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
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 Ubun
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. O
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 n
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.
** 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:
http
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 i
** 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
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/1
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
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.
http
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
** 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:
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
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
** Aff
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
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:
Batt
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:
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
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/BA
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:
Batt
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:
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/
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/186
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:
Batter
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.
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:
Ba
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:
Ba
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
Titl
** 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
Ti
** 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
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:
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')(
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.
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 t
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 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: cham
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 u
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 recei
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
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
** Bu
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:
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.la
** 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 m
** 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 ab
** 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-i
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
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
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, wh
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_CO
s
** 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 notifica
** 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, wh
@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 wh
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 => Confirme
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
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
/de
** 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 no
** 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
T
** 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
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 t
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
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)
** 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 n
> 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.
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
@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 proce
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
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 p
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 notificat
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.
** Change
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.
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
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 wh
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
** 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
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
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
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 commis
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.EF
*** 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 Ubunt
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 ephemer
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 Ubu
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 reconfi
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-
1 - 100 of 205 matches
Mail list logo
