[Bug 1763817] Re: [SRU][BIONIC] after enabling cppc dmesg fills with "ACPI CPPC: PCC check channel failed. Status=0"
>From playing around it appears about 300 seconds after boot. I was able to recreate this with kernel 4.15.0-29-generic but no longer after running apt upgrade and rebooting to the 4.15.0-36-generic kernel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1763817 Title: [SRU][BIONIC] after enabling cppc dmesg fills with "ACPI CPPC: PCC check channel failed. Status=0" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1763817/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1763817] Re: [SRU][BIONIC] after enabling cppc dmesg fills with "ACPI CPPC: PCC check channel failed. Status=0"
I did a clean install of BIONIC via ubuntu-18.04.1-server-arm64.iso on an ARM system and encountered this on first boot. I am happy to send logs but apport-collect states that I am not the owner -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1763817 Title: [SRU][BIONIC] after enabling cppc dmesg fills with "ACPI CPPC: PCC check channel failed. Status=0" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1763817/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1437353] Re: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+
I have already flashed all of my Intel Nics with the latest firmware. I am unable to verify this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1437353 Title: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+ To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1437353/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1582181] Re: AArch64: slow cpuinfo due to redundant loop
My 200+ ARM machine fails to commission in MaaS because lshw takes 8 minutes to run. I will try out this patch and see if it speeds up lshw. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1582181 Title: AArch64: slow cpuinfo due to redundant loop To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1582181/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 919913] Re: cron.d/remote_syslog_compress should skip .bz2 files
maas-region-controller-min which provides /etc/cron.d/maas_remote_syslog_compress also has the same issue. ** Also affects: maas 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/919913 Title: cron.d/remote_syslog_compress should skip .bz2 files To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/919913/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1349949] Re: Juju's mongodb does not need to log every command in syslog
And from MAAS it can be done by adding the following to /etc/maas/preseeds/curtin_userdata late_commands: mongo_01: curtin in-target -- sh -c '/bin/echo :msg, contains, \"authenticate db:\" \~ >> /etc/rsyslog.d/16-mongohush.conf' mongo_02: curtin in-target -- sh -c '/bin/echo :msg, contains, \"warning:\ No such role, \" \~ >> /etc/rsyslog.d/16-mongohush.conf' mongo_03: curtin in-target -- sh -c '/bin/echo :msg, contains, \"command juju.\$cmd command:\" \~ >> /etc/rsyslog.d/16-mongohush.conf' mongo_04: curtin in-target -- sh -c '/bin/echo :msg, contains, \"command presence.\$cmd command:\" \~ >> /etc/rsyslog.d/16-mongohush.conf' -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mongodb in Ubuntu. https://bugs.launchpad.net/bugs/1349949 Title: Juju's mongodb does not need to log every command in syslog To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1349949/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1349949] Re: Juju's mongodb does not need to log every command in syslog
And from MAAS it can be done by adding the following to /etc/maas/preseeds/curtin_userdata late_commands: mongo_01: curtin in-target -- sh -c '/bin/echo :msg, contains, \"authenticate db:\" \~ >> /etc/rsyslog.d/16-mongohush.conf' mongo_02: curtin in-target -- sh -c '/bin/echo :msg, contains, \"warning:\ No such role, \" \~ >> /etc/rsyslog.d/16-mongohush.conf' mongo_03: curtin in-target -- sh -c '/bin/echo :msg, contains, \"command juju.\$cmd command:\" \~ >> /etc/rsyslog.d/16-mongohush.conf' mongo_04: curtin in-target -- sh -c '/bin/echo :msg, contains, \"command presence.\$cmd command:\" \~ >> /etc/rsyslog.d/16-mongohush.conf' -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1349949 Title: Juju's mongodb does not need to log every command in syslog To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1349949/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1392176] Re: mounts cgroups unconditionally which causes undesired effects with cpu hotplug
FYI: My use case for hot plugging my x86 system like a drunken sailor is to evaluate the amount of CPUs required to complete a given task before I schedule it to run on other potentially CPU bound machines. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1392176 Title: mounts cgroups unconditionally which causes undesired effects with cpu hotplug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgmanager/+bug/1392176/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1437353] Re: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+
https://downloadcenter.intel.com/downloads/eula/19186/Intel-Ethernet- Connections-Boot-Utility-Preboot-images-and-EFI- Drivers?httpDown=http%3A%2F%2Fdownloadmirror.intel.com%2F19186%2Feng%2FPreboot.tar.gz ~/APPS/BootUtil/Linux_x64$ sudo ./bootutil64e -IV -ALL Intel(R) Ethernet Flash Firmware Utility BootUtil version 1.5.54.1 Copyright (C) 2003-2015 Intel Corporation Flash firmware on port 1 UEFIx64v4.7.02 Press ENTER key to continue, 'q' to exit:q Port Network Address Location Series WOL Flash FirmwareVersion === === === = === 1 90E2BA5224E8 3:00.0 10GbE N/A UEFI 4.7.02 2 90E2BA5224E9 3:00.1 10GbE N/A UEFI 4.7.02 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1437353 Title: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+ To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1437353/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1449173] Re: maas does not reinstall node
When a nodes is deployed mass
calls/etc/maas/templates/power/ipmi.template which in turn calls
ipmi_chassis_config and specifies /etc/maas/templates/power/ipmi.conf as
the configuration file. The existing configuration files does not
specify whether the boot type is pc-compatible or efi and appears to
default to pc-compatible. If I add the option and specify that the boot
type is efi then the node installs as expected.
grep config /etc/maas/templates/power/ipmi.template
ipmi_chassis_config={{ipmi_chassis_config}}
config={{config_dir}}/{{ipmi_config}}
LC_ALL=C ${ipmi_chassis_config} ${workarounds} ${driver_option} -h
${power_address} ${user_option} -p ${power_pass} --commit --filename ${config}
21)
root: /etc# bzr diff maas/templates/power/ipmi.conf
=== modified file 'maas/templates/power/ipmi.conf'
--- maas/templates/power/ipmi.conf 2015-04-09 18:58:39 +
+++ maas/templates/power/ipmi.conf 2015-04-28 01:46:47 +
@@ -2,6 +2,7 @@
Power_Restore_Policy Off_State_AC_Apply
EndSection
Section Chassis_Boot_Flags
+BIOS_Boot_TypeEFI
Boot_Flags_Persistent No
Boot_Device PXE
EndSection
Should maas set this boot type flag?
Should maas warn the user if machine does not boot off of the network
and instead boots off of the local drive?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to maas in Ubuntu.
https://bugs.launchpad.net/bugs/1449173
Title:
maas does not reinstall node
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1449173/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1449173] Re: maas does not reinstall node
When a nodes is deployed mass
calls/etc/maas/templates/power/ipmi.template which in turn calls
ipmi_chassis_config and specifies /etc/maas/templates/power/ipmi.conf as
the configuration file. The existing configuration files does not
specify whether the boot type is pc-compatible or efi and appears to
default to pc-compatible. If I add the option and specify that the boot
type is efi then the node installs as expected.
grep config /etc/maas/templates/power/ipmi.template
ipmi_chassis_config={{ipmi_chassis_config}}
config={{config_dir}}/{{ipmi_config}}
LC_ALL=C ${ipmi_chassis_config} ${workarounds} ${driver_option} -h
${power_address} ${user_option} -p ${power_pass} --commit --filename ${config}
21)
root: /etc# bzr diff maas/templates/power/ipmi.conf
=== modified file 'maas/templates/power/ipmi.conf'
--- maas/templates/power/ipmi.conf 2015-04-09 18:58:39 +
+++ maas/templates/power/ipmi.conf 2015-04-28 01:46:47 +
@@ -2,6 +2,7 @@
Power_Restore_Policy Off_State_AC_Apply
EndSection
Section Chassis_Boot_Flags
+BIOS_Boot_TypeEFI
Boot_Flags_Persistent No
Boot_Device PXE
EndSection
Should maas set this boot type flag?
Should maas warn the user if machine does not boot off of the network
and instead boots off of the local drive?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1449173
Title:
maas does not reinstall node
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1449173/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1449173] [NEW] maas does not reinstall node
Public bug reported: 1) Commission, acquire, and start a node. Log in to node and touch files in /home/ubunut. Release node INFOMon, 27 April 2015 11:32:24 Node powered off INFOMon, 27 April 2015 11:32:24 Node changed status — From 'Releasing' to 'Ready' INFOMon, 27 April 2015 11:32:18 Node changed status — From 'Deployed' to 'Releasing' INFOMon, 27 April 2015 11:32:18 Powering node off INFOMon, 27 April 2015 11:03:40 Node changed status — From 'Deploying' to 'Deployed' INFOMon, 27 April 2015 11:01:52 Installation complete — Node disabled netboot DEBUG Mon, 27 April 2015 10:57:26 TFTP Request — ubuntu/amd64/generic/trusty/release/di-initrd DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — ubuntu/amd64/generic/trusty/release/di-kernel INFOMon, 27 April 2015 10:57:24 PXE Request — d-i install DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg-90:e2:ba:52:23:20 INFOMon, 27 April 2015 10:57:24 PXE Request — d-i install DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg-90:e2:ba:52:23:20 INFOMon, 27 April 2015 10:57:24 PXE Request — d-i install DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg-90:e2:ba:52:23:20 DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/x86_64-efi/terminal.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grub/x86_64-efi/crypto.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grub/x86_64-efi/fs.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grub/x86_64-efi/command.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grubx64.efi DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — bootx64.efi DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — bootx64.efi INFOMon, 27 April 2015 10:55:10 Node powered on INFOMon, 27 April 2015 10:55:07 Powering node on INFOMon, 27 April 2015 10:55:07 Node changed status — From 'Allocated' to 'Deploying' INFOMon, 27 April 2015 10:55:07 Node changed status — From 'Ready' to 'Allocated' (to userAAA) My expectation is that at this point if I acquire and start the node under a different user the node should be reinstalled and the files in /home/ubuntu should not exist. Instead I see zero TFTP requests because /dev/sda was added as the first entry in the bootlist (see log stating node disabled netboot) and the node simply powers on with the files that I created previously still intact. INFOMon, 27 April 2015 12:15:40 Node powered off INFOMon, 27 April 2015 12:15:40 Node changed status — From 'Releasing' to 'Ready' INFOMon, 27 April 2015 12:15:34 Node changed status — From 'Deployed' to 'Releasing' INFOMon, 27 April 2015 12:15:34 Powering node off INFOMon, 27 April 2015 12:01:00 Node changed status — From 'Deploying' to 'Deployed' INFOMon, 27 April 2015 11:59:06 Node powered on INFOMon, 27 April 2015 11:58:53 Powering node on INFOMon, 27 April 2015 11:58:53 Node changed status — From 'Allocated' to 'Deploying' INFOMon, 27 April 2015 11:58:53 Node changed status — From 'Ready' to 'Allocated' (to userBBB) ** Affects: maas (Ubuntu) Importance: Undecided Status: New ** Attachment added: maas.log and pserv.log https://bugs.launchpad.net/bugs/1449173/+attachment/4385866/+files/maas.tar.gz ** Package changed: grub2 (Ubuntu) = maas (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1449173 Title: maas does not reinstall node To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1449173/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1449173] [NEW] maas does not reinstall node
Public bug reported: 1) Commission, acquire, and start a node. Log in to node and touch files in /home/ubunut. Release node INFOMon, 27 April 2015 11:32:24 Node powered off INFOMon, 27 April 2015 11:32:24 Node changed status — From 'Releasing' to 'Ready' INFOMon, 27 April 2015 11:32:18 Node changed status — From 'Deployed' to 'Releasing' INFOMon, 27 April 2015 11:32:18 Powering node off INFOMon, 27 April 2015 11:03:40 Node changed status — From 'Deploying' to 'Deployed' INFOMon, 27 April 2015 11:01:52 Installation complete — Node disabled netboot DEBUG Mon, 27 April 2015 10:57:26 TFTP Request — ubuntu/amd64/generic/trusty/release/di-initrd DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — ubuntu/amd64/generic/trusty/release/di-kernel INFOMon, 27 April 2015 10:57:24 PXE Request — d-i install DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg-90:e2:ba:52:23:20 INFOMon, 27 April 2015 10:57:24 PXE Request — d-i install DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg-90:e2:ba:52:23:20 INFOMon, 27 April 2015 10:57:24 PXE Request — d-i install DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg-90:e2:ba:52:23:20 DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/grub.cfg DEBUG Mon, 27 April 2015 10:57:24 TFTP Request — /grub/x86_64-efi/terminal.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grub/x86_64-efi/crypto.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grub/x86_64-efi/fs.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grub/x86_64-efi/command.lst DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — /grubx64.efi DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — bootx64.efi DEBUG Mon, 27 April 2015 10:57:23 TFTP Request — bootx64.efi INFOMon, 27 April 2015 10:55:10 Node powered on INFOMon, 27 April 2015 10:55:07 Powering node on INFOMon, 27 April 2015 10:55:07 Node changed status — From 'Allocated' to 'Deploying' INFOMon, 27 April 2015 10:55:07 Node changed status — From 'Ready' to 'Allocated' (to userAAA) My expectation is that at this point if I acquire and start the node under a different user the node should be reinstalled and the files in /home/ubuntu should not exist. Instead I see zero TFTP requests because /dev/sda was added as the first entry in the bootlist (see log stating node disabled netboot) and the node simply powers on with the files that I created previously still intact. INFOMon, 27 April 2015 12:15:40 Node powered off INFOMon, 27 April 2015 12:15:40 Node changed status — From 'Releasing' to 'Ready' INFOMon, 27 April 2015 12:15:34 Node changed status — From 'Deployed' to 'Releasing' INFOMon, 27 April 2015 12:15:34 Powering node off INFOMon, 27 April 2015 12:01:00 Node changed status — From 'Deploying' to 'Deployed' INFOMon, 27 April 2015 11:59:06 Node powered on INFOMon, 27 April 2015 11:58:53 Powering node on INFOMon, 27 April 2015 11:58:53 Node changed status — From 'Allocated' to 'Deploying' INFOMon, 27 April 2015 11:58:53 Node changed status — From 'Ready' to 'Allocated' (to userBBB) ** Affects: maas (Ubuntu) Importance: Undecided Status: New ** Attachment added: maas.log and pserv.log https://bugs.launchpad.net/bugs/1449173/+attachment/4385866/+files/maas.tar.gz ** Package changed: grub2 (Ubuntu) = maas (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to maas in Ubuntu. https://bugs.launchpad.net/bugs/1449173 Title: maas does not reinstall node To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1449173/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1437353] Re: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+
I checked out the latest version of grub, built an image using grub-mknetdir,
and the ARP storm is from the efinet driver. The
code is stuck in the following loop in net/drivers/efi/efinet.c lines 43
through 66. efi_call_3 always returns a txbuf that does not match dev-txbuf,
and eif_call_7 is repeatedly called until the limit_time has been exceeded.
Any thoughts from the grub team on what could be the problem or what I should
do to continue to debug?
while (1)
{
txbuf = NULL;
st = efi_call_3 (net-get_status, net, 0, txbuf);
if (st != GRUB_EFI_SUCCESS)
return grub_error (GRUB_ERR_IO,
N_(couldn't send network packet));
if (txbuf == dev-txbuf)
{
dev-txbusy = 0;
break;
}
if (txbuf)
{
st = efi_call_7 (net-transmit, net, 0, dev-last_pkt_size,
dev-txbuf, NULL, NULL, NULL);
if (st != GRUB_EFI_SUCCESS)
return grub_error (GRUB_ERR_IO,
N_(couldn't send network packet));
}
if (limit_time grub_get_time_ms ())
return grub_error (GRUB_ERR_TIMEOUT,
N_(couldn't send network packet));
}
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437353
Title:
UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit
SFI/SFP+
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1437353/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1437353] Re: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+
The first get status call (efi_call_3(net-get_status, ...)) returns GRUB_EFI_SUCCESS and sets txbuf to 0. The second time this function is called it enters the while loop and the get status call (efi_call_3(net-get_status, ...)) returns GRUB_EFI_SUCCESS and sets txbuf to 1 which does not match the address of dev-txbuf. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1437353 Title: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+ To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1437353/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1437353] Re: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+
Final conclusion. I did not have the latest firmware for the adapter. After updating the firmware I can UEFI boot the system. ** Changed in: maas Status: Triaged = Invalid ** Changed in: grub2 (Ubuntu) Status: New = Invalid ** Changed in: python-tx-tftp Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1437353 Title: UEFI network boot hangs at grub for adapter 82599ES 10-Gigabit SFI/SFP+ To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1437353/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
