[Kernel-packages] [Bug 1870189] Re: initramfs does not get loaded
** Description changed:
- A Gen-1 Ubuntu 19.10 VM on Azure was created and upgraded to Ubuntu
- 20.04 by “do-release-upgrade –d”.
+ [Impact]
+ Generic cloud images will boot without initramfs, fail, and then fall back,
resulting in a double boot performance hit
+
+ [Test Case]
+ Load up cloud images from
http://cloud-images.ubuntu.com/releases/focal/release/.
+
+ For example, using http://cloud-
+ images.ubuntu.com/releases/focal/release/ubuntu-20.04-server-cloudimg-
+ amd64.img :
+
+ qemu-system-x86_64-cpu host -machine type=q35,accel=kvm -m 2048
+ -nographic -snapshot -netdev
+ id=net00,type=user,hostfwd=tcp::-:22 -device virtio-net-
+ pci,netdev=net00 -drive if=virtio,format=qcow2,file=ubuntu-20.04
+ -server-cloudimg-amd64.img -drive if=virtio,format=raw,file=seed.img
+
+ Note: seed.img is created using cloud-localds and a cloud-init file
+ containing ssh keys.
+
+ Observe the double boot.
+
+ On a fixed system, there should only be one boot, and /boot/grub/grubenv
+ should show initrdless_boot_fallback_triggered=0.
+
+ [Regression Potential]
+ Cloud images (both generic and cloud-specific) images perform a double boot.
To mitigate the regression potential, testing will occur for all cloud-specific
kernels as well as all generic cloud images.
+
+
+ [Original Description]
+ A Gen-1 Ubuntu 19.10 VM on Azure was created and upgraded to Ubuntu 20.04 by
“do-release-upgrade –d”.
Then the latest Ubuntu v5.6 kernel was installed from
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6/. As soon as a
reboot was performed, a panic with the v5.6 kernel occured because the
rootfs can not be found.
It turns out by default, initramfs does not get loaded:
/boot/grub/grub.cfg:
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option 'gnulinux-simple-3d2737e8-
b95a-42bf-bac1-bb6fb4cda87f' {
…
- if [ "${initrdfail}" = 1 ]; then
- linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic
- initrd/boot/initrd.img-5.6.0-050600-generic
- else
- linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic panic=-1
- #Dexuan: here the initrd line is missing!
- fi
- initrdfail
+ if [ "${initrdfail}" = 1 ]; then
+ linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic
+ initrd/boot/initrd.img-5.6.0-050600-generic
+ else
+ linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic panic=-1
+ #Dexuan: here the initrd line is missing!
+ fi
+ initrdfail
}
-
- As we can see, Ubuntu only uses the initrd.img if initrdfail=1. Normally,
initrdfail = 0, so when we boot the v5.6 kernel for the first time, we must hit
the “fail to mount rootfs” panic and the kernel will automatically reboot….
+ As we can see, Ubuntu only uses the initrd.img if initrdfail=1.
+ Normally, initrdfail = 0, so when we boot the v5.6 kernel for the first
+ time, we must hit the “fail to mount rootfs” panic and the kernel will
+ automatically reboot….
Also, the “initrdfail” here marks initrdfail=1, so when the kernel boots
for the 2nd time, the kernel should successfully boot up. Next, when
the kernel boots for the 3rd time, it panics again since the userspace
program resets initrdfail to 0, and next time when the kernel boots, it
can boot up successfully -- this “panic/success/panic/success” pattern
repeats forever…
-
The linux-azure kernels are not affected since they have the vmbus driver and
storage drivers built-in (i.e. “=y”):
/boot/config-5.3.0-1013-azure:CONFIG_HYPERV_STORAGE=y
/boot/config-5.3.0-1013-azure:CONFIG_HYPERV=y
/boot/config-5.4.0-1006-azure:CONFIG_HYPERV_STORAGE=y
/boot/config-5.4.0-1006-azure:CONFIG_HYPERV=y
/boot/config-5.6.0-050600-generic:CONFIG_HYPERV_STORAGE=m
/boot/config-5.6.0-050600-generic:CONFIG_HYPERV=m
The v5.6 kernel uses =m rather than =y, so is affected here.
+ It looks the setting may be intentional, but we should not assume a
+ customer kernel must have the necessary vmbus/storage drivers built-in.
- It looks the setting may be intentional, but we should not assume a customer
kernel must have the necessary vmbus/storage drivers built-in.
-
- This issue only happens to the Ubuntu Marketplace image (19.10 and maybe
19.04 as well?) on Azure.
+ This issue only
[Kernel-packages] [Bug 1870189] Re: initramfs does not get loaded
As an update to this bug:
The work to SRU has stalled, as we have found a regression
(https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1902260).
Once a fix is SRU'd to Groovy, I'll pick up the fix and SRU it back to
Focal.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1870189
Title:
initramfs does not get loaded
Status in cloud-images:
Confirmed
Status in grub2 package in Ubuntu:
Won't Fix
Status in linux-azure package in Ubuntu:
Invalid
Status in livecd-rootfs package in Ubuntu:
Triaged
Status in grub2 source package in Focal:
Confirmed
Status in linux-azure source package in Focal:
Invalid
Status in livecd-rootfs source package in Focal:
Confirmed
Bug description:
A Gen-1 Ubuntu 19.10 VM on Azure was created and upgraded to Ubuntu
20.04 by “do-release-upgrade –d”.
Then the latest Ubuntu v5.6 kernel was installed from
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6/. As soon as a
reboot was performed, a panic with the v5.6 kernel occured because the
rootfs can not be found.
It turns out by default, initramfs does not get loaded:
/boot/grub/grub.cfg:
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option 'gnulinux-simple-3d2737e8-
b95a-42bf-bac1-bb6fb4cda87f' {
…
if [ "${initrdfail}" = 1 ]; then
linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic
initrd/boot/initrd.img-5.6.0-050600-generic
else
linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic panic=-1
#Dexuan: here the initrd line is missing!
fi
initrdfail
}
As we can see, Ubuntu only uses the initrd.img if initrdfail=1. Normally,
initrdfail = 0, so when we boot the v5.6 kernel for the first time, we must hit
the “fail to mount rootfs” panic and the kernel will automatically reboot….
Also, the “initrdfail” here marks initrdfail=1, so when the kernel
boots for the 2nd time, the kernel should successfully boot up. Next,
when the kernel boots for the 3rd time, it panics again since the
userspace program resets initrdfail to 0, and next time when the
kernel boots, it can boot up successfully -- this
“panic/success/panic/success” pattern repeats forever…
The linux-azure kernels are not affected since they have the vmbus driver and
storage drivers built-in (i.e. “=y”):
/boot/config-5.3.0-1013-azure:CONFIG_HYPERV_STORAGE=y
/boot/config-5.3.0-1013-azure:CONFIG_HYPERV=y
/boot/config-5.4.0-1006-azure:CONFIG_HYPERV_STORAGE=y
/boot/config-5.4.0-1006-azure:CONFIG_HYPERV=y
/boot/config-5.6.0-050600-generic:CONFIG_HYPERV_STORAGE=m
/boot/config-5.6.0-050600-generic:CONFIG_HYPERV=m
The v5.6 kernel uses =m rather than =y, so is affected here.
It looks the setting may be intentional, but we should not assume a customer
kernel must have the necessary vmbus/storage drivers built-in.
This issue only happens to the Ubuntu Marketplace image (19.10 and maybe
19.04 as well?) on Azure.
We installed a Ubuntu 20.04 VM from the .iso file from
http://cdimage.ubuntu.com/daily-live/pending/ and don’t see the strange grub
issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1870189/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1870189] Re: initramfs does not get loaded
Hi richmbx,
I am currently working this, and currently doing testing to make sure it
has integrated with Focal correctly. I expect it to begin the SRU
process in the next day or so.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1870189
Title:
initramfs does not get loaded
Status in cloud-images:
Confirmed
Status in grub2 package in Ubuntu:
Won't Fix
Status in linux-azure package in Ubuntu:
Invalid
Status in livecd-rootfs package in Ubuntu:
Triaged
Status in grub2 source package in Focal:
Confirmed
Status in linux-azure source package in Focal:
Invalid
Status in livecd-rootfs source package in Focal:
Confirmed
Bug description:
A Gen-1 Ubuntu 19.10 VM on Azure was created and upgraded to Ubuntu
20.04 by “do-release-upgrade –d”.
Then the latest Ubuntu v5.6 kernel was installed from
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6/. As soon as a
reboot was performed, a panic with the v5.6 kernel occured because the
rootfs can not be found.
It turns out by default, initramfs does not get loaded:
/boot/grub/grub.cfg:
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os
$menuentry_id_option 'gnulinux-simple-3d2737e8-
b95a-42bf-bac1-bb6fb4cda87f' {
…
if [ "${initrdfail}" = 1 ]; then
linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic
initrd/boot/initrd.img-5.6.0-050600-generic
else
linux /boot/vmlinuz-5.6.0-050600-generic
root=PARTUUID=bc3d472f-401e-4774-affa-df1acba65a73 ro console=tty1
console=ttyS0 earlyprintk=ttyS0 ignore_loglevel sysrq_always_enabled
unknown_nmi_panic panic=-1
#Dexuan: here the initrd line is missing!
fi
initrdfail
}
As we can see, Ubuntu only uses the initrd.img if initrdfail=1. Normally,
initrdfail = 0, so when we boot the v5.6 kernel for the first time, we must hit
the “fail to mount rootfs” panic and the kernel will automatically reboot….
Also, the “initrdfail” here marks initrdfail=1, so when the kernel
boots for the 2nd time, the kernel should successfully boot up. Next,
when the kernel boots for the 3rd time, it panics again since the
userspace program resets initrdfail to 0, and next time when the
kernel boots, it can boot up successfully -- this
“panic/success/panic/success” pattern repeats forever…
The linux-azure kernels are not affected since they have the vmbus driver and
storage drivers built-in (i.e. “=y”):
/boot/config-5.3.0-1013-azure:CONFIG_HYPERV_STORAGE=y
/boot/config-5.3.0-1013-azure:CONFIG_HYPERV=y
/boot/config-5.4.0-1006-azure:CONFIG_HYPERV_STORAGE=y
/boot/config-5.4.0-1006-azure:CONFIG_HYPERV=y
/boot/config-5.6.0-050600-generic:CONFIG_HYPERV_STORAGE=m
/boot/config-5.6.0-050600-generic:CONFIG_HYPERV=m
The v5.6 kernel uses =m rather than =y, so is affected here.
It looks the setting may be intentional, but we should not assume a customer
kernel must have the necessary vmbus/storage drivers built-in.
This issue only happens to the Ubuntu Marketplace image (19.10 and maybe
19.04 as well?) on Azure.
We installed a Ubuntu 20.04 VM from the .iso file from
http://cdimage.ubuntu.com/daily-live/pending/ and don’t see the strange grub
issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1870189/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1891224] [NEW] [Hyper-V] VSS and File Copy daemons intermittently fails to start
Public bug reported: We have most reliably reproduced this on a Standard_B1s in Azure in the North Europe region (>80% of the time). Tests in other regions/VM types do not show this failure as often (<1%). We have reproduced this in Xenial, Bionic, Focal, and Groovy. We saw an increase of test failures around a month ago. >From the journal : Aug 11 09:55:28 ubuntu systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job sys-devices-virtual-misc-vmbus\x21hv_vss.device/start tim> Aug 11 09:55:28 ubuntu systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_vss.device. Aug 11 09:55:28 ubuntu systemd[1]: Dependency failed for Hyper-V VSS Protocol Daemon. Aug 11 09:55:28 ubuntu systemd[1]: hv-vss-daemon.service: Job hv-vss-daemon.service/start failed with result 'dependency'. Aug 11 09:55:28 ubuntu systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job sys-devices-virtual-misc-vmbus\x21hv_vss.device/start fai> Aug 11 09:55:28 ubuntu systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_fcopy.device: Job sys-devices-virtual-misc-vmbus\x21hv_fcopy.device/start> Aug 11 09:55:28 ubuntu systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_fcopy.device. Aug 11 09:55:28 ubuntu systemd[1]: Dependency failed for Hyper-V File Copy Protocol Daemon. We've seen problems in the past with KVP daemons that looked very similar : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820063 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1891224 Title: [Hyper-V] VSS and File Copy daemons intermittently fails to start Status in linux package in Ubuntu: Incomplete Bug description: We have most reliably reproduced this on a Standard_B1s in Azure in the North Europe region (>80% of the time). Tests in other regions/VM types do not show this failure as often (<1%). We have reproduced this in Xenial, Bionic, Focal, and Groovy. We saw an increase of test failures around a month ago. From the journal : Aug 11 09:55:28 ubuntu systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job sys-devices-virtual-misc-vmbus\x21hv_vss.device/start tim> Aug 11 09:55:28 ubuntu systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_vss.device. Aug 11 09:55:28 ubuntu systemd[1]: Dependency failed for Hyper-V VSS Protocol Daemon. Aug 11 09:55:28 ubuntu systemd[1]: hv-vss-daemon.service: Job hv-vss-daemon.service/start failed with result 'dependency'. Aug 11 09:55:28 ubuntu systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job sys-devices-virtual-misc-vmbus\x21hv_vss.device/start fai> Aug 11 09:55:28 ubuntu systemd[1]: sys-devices-virtual-misc-vmbus\x21hv_fcopy.device: Job sys-devices-virtual-misc-vmbus\x21hv_fcopy.device/start> Aug 11 09:55:28 ubuntu systemd[1]: Timed out waiting for device sys-devices-virtual-misc-vmbus\x21hv_fcopy.device. Aug 11 09:55:28 ubuntu systemd[1]: Dependency failed for Hyper-V File Copy Protocol Daemon. We've seen problems in the past with KVP daemons that looked very similar : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820063 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891224/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev
Yes, we see it on Eoan and blocking tests, so if you could SRU it there, it'd be much appreciated. We have never seen it on Bionic to my knowledge. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: Fix Committed Status in cloud-initramfs-tools package in Ubuntu: Fix Released Status in cloud-utils package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev
Sorry, we were waiting on a bug regarding dictionary keys being modified to resolve before we could verify this. We have not seen this in the past couple of runs in our testing, so I think we're good to proceed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: Fix Committed Status in cloud-initramfs-tools package in Ubuntu: Fix Released Status in cloud-utils package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1820063] Re: [Hyper-V] KVP daemon fails to start on first boot of disco VM
We are no longer seeing this issue with the latest images. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1820063 Title: [Hyper-V] KVP daemon fails to start on first boot of disco VM Status in linux package in Ubuntu: Incomplete Status in linux source package in Xenial: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released Bug description: SRU Justification Impact: The KVP daemon fails to start on first boot due to being started before the hv_kvp device appears. Fix: Update the hv-kvp-daemon service file to start the daemon after device node appears. Regression Potential: The changes are only to the hv-kvp-daemon service file and adding a udev rule, so the worst case regression would be that the service does not start. In testing the service did start as expected. Test Case: See comment #15. --- Launching a recent daily image of disco on azure results in a VM in which the hv-kvp-daemon.service fails to start: $ systemctl status -o cat hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor pr Active: failed (Result: exit-code) since Thu 2019-03-14 13:07:15 UTC; 11min a Main PID: 219 (code=exited, status=1/FAILURE) Started Hyper-V KVP Protocol Daemon. KVP starting; pid is:219 open /dev/vmbus/hv_kvp failed; error: 2 No such file or directory hv-kvp-daemon.service: Main process exited, code=exited, status=1/FAILURE hv-kvp-daemon.service: Failed with result 'exit-code'. The instance was created with: $ az vm create --resource-group [redacted] --image Canonical:UbuntuServer:19.04-DAILY:19.04.201903130 --size Standard_D2_v2 --name disco-0313 As best as I can tell, the /dev/vmbus/hv_kvp isn't available when the hv-kvp-daemon.service starts, but it is available a few seconds later. Manually starting the daemon once I can ssh in works. --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.10-0ubuntu23 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' CRDA: N/A DistroRelease: Ubuntu 19.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: Microsoft Corporation Virtual Machine Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=screen-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcFB: 0 hyperv_fb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-1011-azure root=PARTUUID=11894199-2ca2-4912-9c41-d28128744d57 ro console=tty1 console=ttyS0 panic=-1 ProcVersionSignature: User Name 4.18.0-1011.11-azure 4.18.20 RelatedPackageVersions: linux-restricted-modules-4.18.0-1011-azure N/A linux-backports-modules-4.18.0-1011-azure N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' Tags: disco uec-images Uname: Linux 4.18.0-1011-azure x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm audio cdrom dialout dip floppy netdev plugdev sudo video _MarkForUpload: True dmi.bios.date: 06/02/2017 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 090007 dmi.board.name: Virtual Machine dmi.board.vendor: Microsoft Corporation dmi.board.version: 7.0 dmi.chassis.asset.tag: 7783-7084-3265-9085-8269-3286-77 dmi.chassis.type: 3 dmi.chassis.vendor: Microsoft Corporation dmi.chassis.version: 7.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr090007:bd06/02/2017:svnMicrosoftCorporation:pnVirtualMachine:pvr7.0:rvnMicrosoftCorporation:rnVirtualMachine:rvr7.0:cvnMicrosoftCorporation:ct3:cvr7.0: dmi.product.name: Virtual Machine dmi.product.uuid: 3b0f2160-7fc4-a646-904c-4248f04792d4 dmi.product.version: 7.0 dmi.sys.vendor: Microsoft Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820063/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1841827] Re: Install of linux-modules-nvidia requires a reboot before nvidia-smi recognizes driver
Nouveau was blacklisted in our images, so I am no longer seeing this problem. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1841827 Title: Install of linux-modules-nvidia requires a reboot before nvidia-smi recognizes driver Status in linux-restricted-modules package in Ubuntu: New Bug description: When installing linux-modules-nvidia-418-generic using apt, I expect the nvidia driver to be available immediately after the install completes. However, I must reboot before nvidia-smi returns driver information. AS a side note: sudo udevadm control --reload && sudo udevadm trigger does not cause the driver to appear before the reboot. I was testing this on Disco. System information found in attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/1841827/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev
Adding in a passing version of journalctl ** Attachment added: "passing_journalctl_output.txt" https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5326024/+files/passing_journalctl_output.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev
I'm attaching the output of a failing build ** Attachment added: "failing_journalctl_output.txt" https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5325941/+files/failing_journalctl_output.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev
I can get that going, and will report back on this bug when I have more information. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in linux-azure package in Ubuntu: New Status in systemd package in Ubuntu: Incomplete Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1858844] Re: [Dell XPS 15 9575] Screen brightness stopped working with linux-image-5.4.0-9-generic
For those looking for a workaround in the meantime, I've found that lxqt-config-brightness -i and lxqt-config-brightness -d on the command line are still able to control the screen brightness in my setup. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1858844 Title: [Dell XPS 15 9575] Screen brightness stopped working with linux- image-5.4.0-9-generic Status in linux package in Ubuntu: Confirmed Bug description: I upgraded to Focal Fossa 3 days ago and nothing broke. At the time, it was still using linux 5.3 (linux-image-5.3.0-24-generic). Today, it updated to linux 5.4 (linux-image-5.4.0-9-generic) and after rebooting, the screen brightness does not work anymore - neither from keyboard keys nor from the slider in the gnome-shell panel. It works again when rebooting into the previous linux- image-5.3.0-24-generic kernel. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: linux-image-5.4.0-9-generic 5.4.0-9.12 ProcVersionSignature: Ubuntu 5.4.0-9.12-generic 5.4.3 Uname: Linux 5.4.0-9-generic x86_64 ApportVersion: 2.20.11-0ubuntu15 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: mario 1892 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Wed Jan 8 20:23:31 2020 InstallationDate: Installed on 2018-09-13 (481 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180912) MachineType: Dell Inc. XPS 15 9575 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-9-generic root=UUID=26ff4c95-5f68-4121-b7d0-989fa705fcc8 ro quiet splash RelatedPackageVersions: linux-restricted-modules-5.4.0-9-generic N/A linux-backports-modules-5.4.0-9-generic N/A linux-firmware 1.184 SourcePackage: linux UpgradeStatus: Upgraded to focal on 2020-01-04 (3 days ago) dmi.bios.date: 07/07/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.7.1 dmi.board.name: 0C32VW dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 31 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.7.1:bd07/07/2019:svnDellInc.:pnXPS159575:pvr:rvnDellInc.:rn0C32VW:rvrA00:cvnDellInc.:ct31:cvr: dmi.product.family: XPS dmi.product.name: XPS 15 9575 dmi.product.sku: 080D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858844/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1841827] Re: Install of linux-modules-nvidia requires a reboot before nvidia-smi recognizes driver
So after doing a little more digging: A modprobe -r nouveau will fix this. After issuing this command, an install does not require a reboot for nvidia-smi to find the driver. We are planning on blacklisting the module in our cloud images to address this. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1841827 Title: Install of linux-modules-nvidia requires a reboot before nvidia-smi recognizes driver Status in linux-restricted-modules package in Ubuntu: New Bug description: When installing linux-modules-nvidia-418-generic using apt, I expect the nvidia driver to be available immediately after the install completes. However, I must reboot before nvidia-smi returns driver information. AS a side note: sudo udevadm control --reload && sudo udevadm trigger does not cause the driver to appear before the reboot. I was testing this on Disco. System information found in attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/1841827/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1841827] [NEW] Install of linux-modules-nviida requires a reboot before nvidia-smi recognizes driver
Public bug reported: When installing linux-modules-nvidia-418-generic using apt, I expect the nvidia driver to be available immediately after the install completes. However, I must reboot before nvidia-smi returns driver information. AS a side note: sudo udevadm control --reload && sudo udevadm trigger does not cause the driver to appear before the reboot. I was testing this on Disco. System information found in attachment. ** Affects: linux-restricted-modules (Ubuntu) Importance: Undecided Status: New ** Attachment added: "System information" https://bugs.launchpad.net/bugs/1841827/+attachment/5285467/+files/disco-sysinfo -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1841827 Title: Install of linux-modules-nviida requires a reboot before nvidia-smi recognizes driver Status in linux-restricted-modules package in Ubuntu: New Bug description: When installing linux-modules-nvidia-418-generic using apt, I expect the nvidia driver to be available immediately after the install completes. However, I must reboot before nvidia-smi returns driver information. AS a side note: sudo udevadm control --reload && sudo udevadm trigger does not cause the driver to appear before the reboot. I was testing this on Disco. System information found in attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/1841827/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT
** Description changed: CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0". This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37. patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp ii linux-gcp4.15.0.1037.51 amd64Complete Google Cloud Platform (GCP) Linux kernel and headers ii linux-gcp-headers-4.15.0-10374.15.0-1037.39~16.04.1 amd64Header files related to Linux kernel version 4.15.0 To reproduce: 1) Create an image with a disk size of 3072 using a serial that has GPT gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 Reboot the instance 2) It will hang on reboot and you cannot connect 3) Please note that later serials have the GPT change reverted. You can replace xenial with bionic in the above commands to get a bionic instance instead. - To test this out in a more slower fashion: - 1) Create an image with a disk size of 2048 using a serial that has GPT gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048 2) Resize the disk to 3072 3) Issue growpart /dev/sda 1 4) Issue resize2fs /dev/sda1 - 5) Issue rsize2fs /dev/sda1 instead + 5) Issue rsize2fs /dev/sda1 again On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize. - - I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. + I've tried starting from a Xenial instance and doing a do-release- + upgrade to get to bionic and then doing the growpart/resize2fs, but the + issue still shows up. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gcp in Ubuntu. https://bugs.launchpad.net/bugs/1840686 Title: Xenial images won't reboot if disk size is > 2TB when using GPT Status in cloud-init: New Status in linux-gcp package in Ubuntu: New Bug description: CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0". This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37. patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp ii linux-gcp4.15.0.1037.51 amd64Complete Google Cloud Platform (GCP) Linux kernel and headers ii linux-gcp-headers-4.15.0-10374.15.0-1037.39~16.04.1 amd64Header files related to Linux kernel version 4.15.0 To reproduce: 1) Create an image with a disk size of 3072 using a serial that has GPT gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 Reboot the instance 2) It will hang on reboot and you cannot connect 3) Please note that later serials have the GPT change reverted. You can replace xenial with bionic in the above commands to get a bionic instance instead. To test this out in a more slower fashion: 1) Create an image with a disk size of 2048 using a serial that has GPT gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048 2) Resize the disk to 3072 3) Issue growpart /dev/sda 1 4) Issue resize2fs /dev/sda1 5) Issue rsize2fs /dev/sda1 again On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize. I've tried starting from a Xenial instance and doing a do-release- upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1840686/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More
[Kernel-packages] [Bug 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT
At first I thought it was related to https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=1e19b01be31fc5264a84d246023ecf29e44949df=25=0=0, and later I thought it was related to https://bugs.launchpad.net/bugs/1762748. However, I added the bionic archives to my Xenial instance and updated e2fsprogs and cloud-utils, then tried to grow the disk past 2048, and ran into the reboot issue again. I agree it was very close to, and the recreate information in that bug helped me narrow down what I was seeing. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gcp in Ubuntu. https://bugs.launchpad.net/bugs/1840686 Title: Xenial images won't reboot if disk size is > 2TB when using GPT Status in cloud-init: New Status in linux-gcp package in Ubuntu: New Bug description: CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0". This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37. patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp ii linux-gcp4.15.0.1037.51 amd64Complete Google Cloud Platform (GCP) Linux kernel and headers ii linux-gcp-headers-4.15.0-10374.15.0-1037.39~16.04.1 amd64Header files related to Linux kernel version 4.15.0 To reproduce: 1) Create an image with a disk size of 3072 using a serial that has GPT gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 Reboot the instance 2) It will hang on reboot and you cannot connect 3) Please note that later serials have the GPT change reverted. You can replace xenial with bionic in the above commands to get a bionic instance instead. To test this out in a more slower fashion: 1) Create an image with a disk size of 2048 using a serial that has GPT gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048 2) Resize the disk to 3072 3) Issue growpart /dev/sda 1 4) Issue resize2fs /dev/sda1 5) Issue rsize2fs /dev/sda1 instead On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize. I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1840686/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1840710] [NEW] EULA never offered for Nvidia drivers install
Public bug reported: Relevant system information here: https://pastebin.canonical.com/p/q6XqWt6THQ/ I was expecting that when I installed linux-modules-nvidia-generic-418 that I would get an option to accept or reject a EULA. However, on installation, no prompt is given to me, and after a reboot, I am able to see the driver with a `nvidia-smi` command. After doing some digging, installing this package writes out /etc/default/linux-modules-nvidia with latelink=true, and my debconf database also has a boolean for nvidia latelink set to true. ** Affects: linux-restricted-modules (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-restricted-modules in Ubuntu. https://bugs.launchpad.net/bugs/1840710 Title: EULA never offered for Nvidia drivers install Status in linux-restricted-modules package in Ubuntu: New Bug description: Relevant system information here: https://pastebin.canonical.com/p/q6XqWt6THQ/ I was expecting that when I installed linux-modules-nvidia-generic-418 that I would get an option to accept or reject a EULA. However, on installation, no prompt is given to me, and after a reboot, I am able to see the driver with a `nvidia-smi` command. After doing some digging, installing this package writes out /etc/default/linux-modules-nvidia with latelink=true, and my debconf database also has a boolean for nvidia latelink set to true. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/1840710/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1840686] [NEW] Xenial images won't reboot if disk size is > 2TB when using GPT
Public bug reported: CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0". This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37. patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp ii linux-gcp4.15.0.1037.51 amd64Complete Google Cloud Platform (GCP) Linux kernel and headers ii linux-gcp-headers-4.15.0-10374.15.0-1037.39~16.04.1 amd64Header files related to Linux kernel version 4.15.0 To reproduce: 1) Create an image with a disk size of 3072 using a serial that has GPT gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 Reboot the instance 2) It will hang on reboot and you cannot connect 3) Please note that later serials have the GPT change reverted. You can replace xenial with bionic in the above commands to get a bionic instance instead. To test this out in a more slower fashion: 1) Create an image with a disk size of 2048 using a serial that has GPT gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048 2) Resize the disk to 3072 3) Issue growpart /dev/sda 1 4) Issue resize2fs /dev/sda1 5) Issue rsize2fs /dev/sda1 instead On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize. I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. ** Affects: linux-gcp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gcp in Ubuntu. https://bugs.launchpad.net/bugs/1840686 Title: Xenial images won't reboot if disk size is > 2TB when using GPT Status in linux-gcp package in Ubuntu: New Bug description: CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0". This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37. patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp ii linux-gcp4.15.0.1037.51 amd64Complete Google Cloud Platform (GCP) Linux kernel and headers ii linux-gcp-headers-4.15.0-10374.15.0-1037.39~16.04.1 amd64Header files related to Linux kernel version 4.15.0 To reproduce: 1) Create an image with a disk size of 3072 using a serial that has GPT gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 Reboot the instance 2) It will hang on reboot and you cannot connect 3) Please note that later serials have the GPT change reverted. You can replace xenial with bionic in the above commands to get a bionic instance instead. To test this out in a more slower fashion: 1) Create an image with a disk size of 2048 using a serial that has GPT gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048 2) Resize the disk to 3072 3) Issue growpart /dev/sda 1 4) Issue resize2fs /dev/sda1 5) Issue rsize2fs /dev/sda1 instead On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize. I've tried starting from a Xenial instance and doing a do-release-upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/1840686/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
