[Kernel-packages] [Bug 1829749] Re: [MIR] Please add support for SIPL
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
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/1829749
Title:
[MIR] Please add support for SIPL
Status in Launchpad itself:
Fix Released
Status in linux package in Ubuntu:
New
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
Fix Released
Status in s390-tools-signed package in Ubuntu:
Fix Released
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1829749] Re: [MIR] Please add support for SIPL
https://lists.ubuntu.com/archives/kernel-team/2019-July/102204.html
https://lists.ubuntu.com/archives/kernel-team/2019-July/102205.html
--
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/1829749
Title:
[MIR] Please add support for SIPL
Status in Launchpad itself:
Fix Released
Status in linux package in Ubuntu:
Incomplete
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
Fix Released
Status in s390-tools-signed package in Ubuntu:
Fix Released
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1836902] [NEW] zfs-units fire by default on host and container, even when there are no zfs filesystems
Public bug reported: zfs-units fire by default on host and container, even when there are no zfs filesystems instead of enabling units by default, they should be pulled in by udev. udev already modprobes zfs module when it notices any zfs filesystems, and it should also enable the scan/import/etc units. This way on systems without any zfs attached, the units are innert and do not cause system to be in degraded state. ** Affects: zfs-linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1836902 Title: zfs-units fire by default on host and container, even when there are no zfs filesystems Status in zfs-linux package in Ubuntu: New Bug description: zfs-units fire by default on host and container, even when there are no zfs filesystems instead of enabling units by default, they should be pulled in by udev. udev already modprobes zfs module when it notices any zfs filesystems, and it should also enable the scan/import/etc units. This way on systems without any zfs attached, the units are innert and do not cause system to be in degraded state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1836902/+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 1837332] [NEW] Please enable CONFIG_SCSI_UFS_QCOM as a module on arm64
Public bug reported: Enable CONFIG_SCSI_UFS_QCOM as a module on arm64. SCSI_UFS_QCOM this enables UFS storage on QCOM based laptops such as Lenovo Yoga C630. ** Affects: linux (Ubuntu) Importance: Undecided Status: In Progress ** Changed in: linux (Ubuntu) Status: New => In Progress -- 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/1837332 Title: Please enable CONFIG_SCSI_UFS_QCOM as a module on arm64 Status in linux package in Ubuntu: In Progress Bug description: Enable CONFIG_SCSI_UFS_QCOM as a module on arm64. SCSI_UFS_QCOM this enables UFS storage on QCOM based laptops such as Lenovo Yoga C630. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837332/+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 1837332] Re: Please enable CONFIG_SCSI_UFS_QCOM as a module on arm64
https://lists.ubuntu.com/archives/kernel-team/2019-July/102465.html -- 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/1837332 Title: Please enable CONFIG_SCSI_UFS_QCOM as a module on arm64 Status in linux package in Ubuntu: In Progress Bug description: Enable CONFIG_SCSI_UFS_QCOM as a module on arm64. SCSI_UFS_QCOM this enables UFS storage on QCOM based laptops such as Lenovo Yoga C630. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837332/+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
It's funny how long it took them to figure it out, but yes https://bugzilla.redhat.com/show_bug.cgi?id=1195029#c22 is the right answer. Please use that patch / combination of tagging the device with tag&wants using udev rule + making the service bind to it. -- 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: Confirmed Bug description: 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 1823056] [NEW] autopkgtests run too often, too much and don't skip enough
Public bug reported: [Impact] * linux autopkgtest should only execute either rebuild tests, when triggered by toolchain. or execute regression suite when triggered by meta but never both. As otherwise, it results in false negative results for the kernel [Test Case] * Trigger adt test of linux with a matching linux-meta. Check that rebuild test is skipped, and that the regression suite test runs. * trigger adt test of linux with triggered by gcc-6/7/8 (as appropriate) and observe that rebuild test runs, and regression suite test is skipped. * (when this is applied to flavours) trigger adt test of linux-* with a matching flavour meta, and check that regression test-suite is skipped on kernels that cannot boot in scaling stack (e.g. gcp, azure, aws, etc) [Fix] * debian/tests/* are modified to pay more attention as to what they are triggered by, and raise appropriate skipped error codes [Regression Potential] * incorrect tests may run at incorrect time is the regression potential here, hence the two test cases verify that the right tests are executed when expected. * care was taken to take into account all linux kernel flavours, hence the third test case need to be reverified on flavoured kernels. [Other Info] * affects all stable series xenial and up, across all kernel flavours ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1823056 Title: autopkgtests run too often, too much and don't skip enough Status in linux package in Ubuntu: New Bug description: [Impact] * linux autopkgtest should only execute either rebuild tests, when triggered by toolchain. or execute regression suite when triggered by meta but never both. As otherwise, it results in false negative results for the kernel [Test Case] * Trigger adt test of linux with a matching linux-meta. Check that rebuild test is skipped, and that the regression suite test runs. * trigger adt test of linux with triggered by gcc-6/7/8 (as appropriate) and observe that rebuild test runs, and regression suite test is skipped. * (when this is applied to flavours) trigger adt test of linux-* with a matching flavour meta, and check that regression test-suite is skipped on kernels that cannot boot in scaling stack (e.g. gcp, azure, aws, etc) [Fix] * debian/tests/* are modified to pay more attention as to what they are triggered by, and raise appropriate skipped error codes [Regression Potential] * incorrect tests may run at incorrect time is the regression potential here, hence the two test cases verify that the right tests are executed when expected. * care was taken to take into account all linux kernel flavours, hence the third test case need to be reverified on flavoured kernels. [Other Info] * affects all stable series xenial and up, across all kernel flavours To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056/+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 1534162] Re: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs
** Also affects: subiquity Importance: Undecided Status: New ** Tags added: rls-dd-incoming -- 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/1534162 Title: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs Status in subiquity: New Status in linux package in Ubuntu: Confirmed Status in livecd-rootfs package in Ubuntu: New Status in zipl-installer package in Ubuntu: Confirmed Bug description: Symlinks are not managed correctly. Last installed and configured kernel, prior to purging -5- was -6-, yet symlinks were not updated to -6- when that happened. root@devac03:~# apt-get remove --purge linux-headers-4.3.0-5 linux-headers-4.3.0-5-generic linux-image-4.3.0-5-generic linux-image-extra-4.3.0-5-generic Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.3.0-5* linux-headers-4.3.0-5-generic* linux-image-4.3.0-5-generic* linux-image-extra-4.3.0-5-generic* 0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded. After this operation, 131 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 92073 files and directories currently installed.) Removing linux-headers-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-headers-4.3.0-5 (4.3.0-5.16) ... Removing linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Generating /boot/initrd.img-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. run-parts: executing /etc/kernel/postinst.d/pm-utils 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. Purging configuration files for linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-image-4.3.0-5-generic (4.3.0-5.16) ... WARN: Proceeding with removing running kernel image. Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Deleting /boot/initrd.img-4.3.0-5-generic run-parts: executing /etc/kernel/postrm.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Error: Image file '/boot/vmlinuz' in section 'ubuntu': No such file or directory run-parts: /etc/kernel/postrm.d/zz-zipl exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-4.3.0-5-generic.postrm line 328. dpkg: error processing package linux-image-4.3.0-5-generic (--purge): subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: linux-image-4.3.0-5-generic E: Sub-process /usr/bin/dpkg returned an error code (1) root@devac03:~# ls -latr /boot total 24208 drwx-- 2 root root16384 Dec 9 16:38 lost+found lrwxrwxrwx 1 root root 26 Jan 6 16:23 initrd.img -> initrd.img-4.3.0-5-generic lrwxrwxrwx 1 root root 23 Jan 6 16:24 vmlinuz -> vmlinuz-4.3.0-5-generic -rw--- 1 root root 13026048 Jan 11 21:36 vmlinuz-4.3.0-6-generic -rw--- 1 root root 2446124 Jan 11 21:36 System.map-4.3.0-6-generic -rw-r--r-- 1 root root63422 Jan 11 21:36 config-4.3.0-6-generic -rw-r--r-- 1 root root 517933 Jan 11 21:36 abi-4.3.0-6-generic drwxr-xr-x 22 root root 4096 Jan 14 13:03 .. -rw-r--r-- 1 root root 8574889 Jan 14 13:03 initrd.img-4.3.0-6-generic -rw--- 1 root root69632 Jan 14 13:41 bootmap drwxr-xr-x 3 root root 4096 Jan 14 13:41 . root@devac03:~# dpkg -l | grep 4.3.0 ii iproute 1:4.3.0-1ubuntu1 all transitional dummy package for iproute2 ii iproute2 4.3.0-1ubuntu1 s390xnetworking and traffic control tools ii linux-generic4.3.0.6.7 s390xComplete Generic Linux kernel and headers ii linux-headers-4.3.0-64.3.0-6.17 all Header files related to Linux kernel version 4.3.0 ii linux-headers-4.3.0-6-generic4.3.0-6.17 s390xLinux k
[Kernel-packages] [Bug 1534162] Re: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs
I think last time it was fixed by fixing base-installer. http://launchpadlibrarian.net/235185956/base-installer_1.158ubuntu1_1.158ubuntu2.diff.gz but this time around, we need to decide who/what/where should write out kernel-img.conf. because we do not have kernel-common by default. ** Also affects: base-installer (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: zipl-installer (Ubuntu) Status: Confirmed => Fix Released ** Changed in: subiquity Status: New => Confirmed ** Changed in: base-installer (Ubuntu) Status: New => Fix Released -- 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/1534162 Title: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs Status in subiquity: Confirmed Status in base-installer package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in livecd-rootfs package in Ubuntu: New Status in zipl-installer package in Ubuntu: Fix Released Bug description: Symlinks are not managed correctly. Last installed and configured kernel, prior to purging -5- was -6-, yet symlinks were not updated to -6- when that happened. root@devac03:~# apt-get remove --purge linux-headers-4.3.0-5 linux-headers-4.3.0-5-generic linux-image-4.3.0-5-generic linux-image-extra-4.3.0-5-generic Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.3.0-5* linux-headers-4.3.0-5-generic* linux-image-4.3.0-5-generic* linux-image-extra-4.3.0-5-generic* 0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded. After this operation, 131 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 92073 files and directories currently installed.) Removing linux-headers-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-headers-4.3.0-5 (4.3.0-5.16) ... Removing linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Generating /boot/initrd.img-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. run-parts: executing /etc/kernel/postinst.d/pm-utils 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. Purging configuration files for linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-image-4.3.0-5-generic (4.3.0-5.16) ... WARN: Proceeding with removing running kernel image. Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Deleting /boot/initrd.img-4.3.0-5-generic run-parts: executing /etc/kernel/postrm.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Error: Image file '/boot/vmlinuz' in section 'ubuntu': No such file or directory run-parts: /etc/kernel/postrm.d/zz-zipl exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-4.3.0-5-generic.postrm line 328. dpkg: error processing package linux-image-4.3.0-5-generic (--purge): subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: linux-image-4.3.0-5-generic E: Sub-process /usr/bin/dpkg returned an error code (1) root@devac03:~# ls -latr /boot total 24208 drwx-- 2 root root16384 Dec 9 16:38 lost+found lrwxrwxrwx 1 root root 26 Jan 6 16:23 initrd.img -> initrd.img-4.3.0-5-generic lrwxrwxrwx 1 root root 23 Jan 6 16:24 vmlinuz -> vmlinuz-4.3.0-5-generic -rw--- 1 root root 13026048 Jan 11 21:36 vmlinuz-4.3.0-6-generic -rw--- 1 root root 2446124 Jan 11 21:36 System.map-4.3.0-6-generic -rw-r--r-- 1 root root63422 Jan 11 21:36 config-4.3.0-6-generic -rw-r--r-- 1 root root 517933 Jan 11 21:36 abi-4.3.0-6-generic drwxr-xr-x 22 root root 4096 Jan 14 13:03 .. -rw-r--r-- 1 root root 8574889 Jan 14 13:03 initrd.img-4.3.0-6-generic -rw--- 1 root root69632 Jan 14 13:41 bootmap drwxr-xr-x 3 root root 4096 Jan 14 13:41 . root@devac03:~# dpkg -l | grep 4.3.0 ii iproute
[Kernel-packages] [Bug 1534162] Re: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs
** Also affects: curtin Importance: Undecided Status: New ** Changed in: livecd-rootfs (Ubuntu) Status: New => Invalid ** Changed in: curtin Status: New => Confirmed -- 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/1534162 Title: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs Status in curtin: Confirmed Status in subiquity: Confirmed Status in base-installer package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Status in livecd-rootfs package in Ubuntu: Invalid Status in zipl-installer package in Ubuntu: Fix Released Bug description: On Ubuntu/Debian like systems /etc/kernel-img.conf should be created by the "installer". It is currently done by base-installer/live-installer/ubiquity but not curtin, but it should be. At the moment we require kernel-img.conf and we do not have the correct per-arch built-in defaults for its settings in all of our kernels. It is not a config file, nor is it created by livecd-rootfs (after all our squashfs might be containers, and never live to install kernels and bootloaders). One day we might fix our kernels to not require kernel-img.conf, but until then curtin should be generating the right one. Making a merge proposal to fix this in curtin by mimicking what base-installer did. == Symlinks are not managed correctly. Last installed and configured kernel, prior to purging -5- was -6-, yet symlinks were not updated to -6- when that happened. root@devac03:~# apt-get remove --purge linux-headers-4.3.0-5 linux-headers-4.3.0-5-generic linux-image-4.3.0-5-generic linux-image-extra-4.3.0-5-generic Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.3.0-5* linux-headers-4.3.0-5-generic* linux-image-4.3.0-5-generic* linux-image-extra-4.3.0-5-generic* 0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded. After this operation, 131 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 92073 files and directories currently installed.) Removing linux-headers-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-headers-4.3.0-5 (4.3.0-5.16) ... Removing linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Generating /boot/initrd.img-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. run-parts: executing /etc/kernel/postinst.d/pm-utils 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. Purging configuration files for linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-image-4.3.0-5-generic (4.3.0-5.16) ... WARN: Proceeding with removing running kernel image. Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Deleting /boot/initrd.img-4.3.0-5-generic run-parts: executing /etc/kernel/postrm.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Error: Image file '/boot/vmlinuz' in section 'ubuntu': No such file or directory run-parts: /etc/kernel/postrm.d/zz-zipl exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-4.3.0-5-generic.postrm line 328. dpkg: error processing package linux-image-4.3.0-5-generic (--purge): subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: linux-image-4.3.0-5-generic E: Sub-process /usr/bin/dpkg returned an error code (1) root@devac03:~# ls -latr /boot total 24208 drwx-- 2 root root16384 Dec 9 16:38 lost+found lrwxrwxrwx 1 root root 26 Jan 6 16:23 initrd.img -> initrd.img-4.3.0-5-generic lrwxrwxrwx 1 root root 23 Jan 6 16:24 vmlinuz -> vmlinuz-4.3.0-5-generic -rw--- 1 root root 13026048 Jan 11 21:36 vmlinuz-4.3.0-6-generic -rw--- 1 root root 2446124 Jan 11 21:36 System.map-4.3.0-6-generic -rw-r--r-- 1 root root63422 Jan 11 21:36 config-4.3.0-6-generic -rw-r--r-- 1 root root 517933 Jan 11 21:36 abi-4.3.0-6-generic drwxr-xr-x 22 r
[Kernel-packages] [Bug 1534162] Re: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs
** Description changed: + + On Ubuntu/Debian like systems /etc/kernel-img.conf should be created by the "installer". It is currently done by base-installer/live-installer/ubiquity but not curtin, but it should be. At the moment we require kernel-img.conf and we do not have the correct per-arch built-in defaults for its settings in all of our kernels. It is not a config file, nor is it created by livecd-rootfs (after all our squashfs might be containers, and never live to install kernels and bootloaders). + + One day we might fix our kernels to not require kernel-img.conf, but + until then curtin should be generating the right one. Making a merge + proposal to fix this in curtin by mimicking what base-installer did. + + == + Symlinks are not managed correctly. Last installed and configured kernel, prior to purging -5- was -6-, yet symlinks were not updated to -6- when that happened. root@devac03:~# apt-get remove --purge linux-headers-4.3.0-5 linux-headers-4.3.0-5-generic linux-image-4.3.0-5-generic linux-image-extra-4.3.0-5-generic Reading package lists... Done - Building dependency tree + Building dependency tree Reading state information... Done The following packages will be REMOVED: - linux-headers-4.3.0-5* linux-headers-4.3.0-5-generic* linux-image-4.3.0-5-generic* - linux-image-extra-4.3.0-5-generic* + linux-headers-4.3.0-5* linux-headers-4.3.0-5-generic* linux-image-4.3.0-5-generic* + linux-image-extra-4.3.0-5-generic* 0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded. After this operation, 131 MB disk space will be freed. Do you want to continue? [Y/n] Y (Reading database ... 92073 files and directories currently installed.) Removing linux-headers-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-headers-4.3.0-5 (4.3.0-5.16) ... Removing linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Generating /boot/initrd.img-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. run-parts: executing /etc/kernel/postinst.d/pm-utils 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic run-parts: executing /etc/kernel/postinst.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Building bootmap in '/boot/' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'ubuntu' (default) Preparing boot device: dasda (0200). Done. Purging configuration files for linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ... Removing linux-image-4.3.0-5-generic (4.3.0-5.16) ... WARN: Proceeding with removing running kernel image. Examining /etc/kernel/postrm.d . run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic update-initramfs: Deleting /boot/initrd.img-4.3.0-5-generic run-parts: executing /etc/kernel/postrm.d/zz-zipl 4.3.0-5-generic /boot/vmlinuz-4.3.0-5-generic Using config file '/etc/zipl.conf' Error: Image file '/boot/vmlinuz' in section 'ubuntu': No such file or directory run-parts: /etc/kernel/postrm.d/zz-zipl exited with return code 1 Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-4.3.0-5-generic.postrm line 328. dpkg: error processing package linux-image-4.3.0-5-generic (--purge): - subprocess installed post-removal script returned error exit status 1 + subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: - linux-image-4.3.0-5-generic + linux-image-4.3.0-5-generic E: Sub-process /usr/bin/dpkg returned an error code (1) root@devac03:~# ls -latr /boot total 24208 drwx-- 2 root root16384 Dec 9 16:38 lost+found lrwxrwxrwx 1 root root 26 Jan 6 16:23 initrd.img -> initrd.img-4.3.0-5-generic lrwxrwxrwx 1 root root 23 Jan 6 16:24 vmlinuz -> vmlinuz-4.3.0-5-generic -rw--- 1 root root 13026048 Jan 11 21:36 vmlinuz-4.3.0-6-generic -rw--- 1 root root 2446124 Jan 11 21:36 System.map-4.3.0-6-generic -rw-r--r-- 1 root root63422 Jan 11 21:36 config-4.3.0-6-generic -rw-r--r-- 1 root root 517933 Jan 11 21:36 abi-4.3.0-6-generic drwxr-xr-x 22 root root 4096 Jan 14 13:03 .. -rw-r--r-- 1 root root 8574889 Jan 14 13:03 initrd.img-4.3.0-6-generic -rw--- 1 root root69632 Jan 14 13:41 bootmap drwxr-xr-x 3 root root 4096 Jan 14 13:41 . root@devac03:~# dpkg -l | grep 4.3.0 ii iproute 1:4.3.0-1ubuntu1 all transitional dummy package for iproute2 ii iproute2 4.3.0-1ubuntu1
[Kernel-packages] [Bug 1824407] [NEW] why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather
Public bug reported: Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6ff3660032757063 Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6ff3660032757063] Apr 11 18:32:55 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6261746d79732e Apr 11 18:32:55 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6261746d79732e] Apr 11 18:33:05 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6ff366df00333a37 Apr 11 18:33:05 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6ff366df00333a37] Happens when booting e.g. subiquity disco image. v5.0.0-8-generic kernel ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1824407 Title: why does booting any livefs squashfs has kernel complaining about unable to read metadata something rather Status in linux package in Ubuntu: New Bug description: Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6ff3660032757063 Apr 11 18:32:52 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6ff3660032757063] Apr 11 18:32:55 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6261746d79732e Apr 11 18:32:55 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6261746d79732e] Apr 11 18:33:05 ubuntu-server kernel: SQUASHFS error: squashfs_read_data failed to read block 0x6ff366df00333a37 Apr 11 18:33:05 ubuntu-server kernel: SQUASHFS error: Unable to read metadata cache entry [6ff366df00333a37] Happens when booting e.g. subiquity disco image. v5.0.0-8-generic kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824407/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
got a few more tweaks to the storage test, and it's now more consistently passing on all other architectures but ppc64le. -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1824863] [NEW] CONFIG_LOG_BUF_SHIFT is too low on arm64
Public bug reported:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
Please backport this to xenial and up.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
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/1824863
Title:
CONFIG_LOG_BUF_SHIFT is too low on arm64
Status in linux package in Ubuntu:
New
Bug description:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
Please backport this to xenial and up.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824863/+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 1824864] [NEW] CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Public bug reported:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
Please backport this to xenial and up.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Disco)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Ee-series)
Importance: Undecided
Status: New
** Tags: bot-stop-nagging
** Tags added: bot-stop-nagging
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Ee-series)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Disco)
Importance: Undecided
Status: New
** Summary changed:
- CONFIG_LOG_BUF_SHIFT is too low on arm64
+ CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
--
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/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Status in linux package in Ubuntu:
New
Status in linux source package in Xenial:
New
Status in linux source package in Bionic:
New
Status in linux source package in Cosmic:
New
Status in linux source package in Disco:
New
Status in linux source package in EE-Series:
New
Bug description:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
Please backport this to xenial and up.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+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 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
** Description changed:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
- int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
- range 12 25
- default 17
- depends on PRINTK
- help
- Select the minimal kernel log buffer size as a power of 2.
- The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
- parameter, see below. Any higher size also might be forced
- by "log_buf_len" boot parameter.
+ int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
+ range 12 25
+ default 17
+ depends on PRINTK
+ help
+ Select the minimal kernel log buffer size as a power of 2.
+ The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
+ parameter, see below. Any higher size also might be forced
+ by "log_buf_len" boot parameter.
- Examples:
- 17 => 128 KB
- 16 => 64 KB
- 15 => 32 KB
- 14 => 16 KB
- 13 => 8 KB
- 12 => 4 KB
+ Examples:
+ 17 => 128 KB
+ 16 => 64 KB
+ 15 => 32 KB
+ 14 => 16 KB
+ 13 => 8 KB
+ 12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
+ On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
+ I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
+
+
Please backport this to xenial and up.
** Changed in: linux (Ubuntu Disco)
Status: Incomplete => Confirmed
** Changed in: linux (Ubuntu Cosmic)
Status: Incomplete => Confirmed
** Changed in: linux (Ubuntu Bionic)
Status: Incomplete => Confirmed
** Changed in: linux (Ubuntu Xenial)
Status: Incomplete => Confirmed
** Changed in: linux (Ubuntu Ee-series)
Status: New => Confirmed
--
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/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Status in linux source package in Disco:
Confirmed
Status in linux source package in EE-Series:
Confirmed
Bug description:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
Please backport this to xenial and up.
To manage notifications about this bug go to:
htt
[Kernel-packages] [Bug 1824863] Re: CONFIG_LOG_BUF_SHIFT is too low on arm64
*** This bug is a duplicate of bug 1824864 ***
https://bugs.launchpad.net/bugs/1824864
** This bug has been marked a duplicate of bug 1824864
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
--
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/1824863
Title:
CONFIG_LOG_BUF_SHIFT is too low on arm64
Status in linux package in Ubuntu:
Incomplete
Bug description:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
Please backport this to xenial and up.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824863/+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 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
+ Please backport this to xenial and up.
- Please backport this to xenial and up.
+
+
+ === systemd ===
+
+ systemd, boot-and-services test case can bump the ring buffer before
+ running the tests.
--
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/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Status in linux package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
New
Status in linux source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
New
Status in linux source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
New
Status in linux source package in Cosmic:
Confirmed
Status in systemd source package in Cosmic:
New
Status in linux source package in Disco:
Confirmed
Status in systemd source package in Disco:
New
Status in linux source package in EE-Series:
Confirmed
Status in systemd source package in EE-Series:
New
Bug description:
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
Please backport this to xenial and up.
=== systemd ===
systemd, boot-and-services test case can bump the ring buffer before
running the tests.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+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 1840945] Re: Concatenated lz4 initrds don't work
`| lz4 > date.img` is incorrect One must use `lz4 -9 -l` For xz one should use `xz --check=crc32` -- 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/1840945 Title: Concatenated lz4 initrds don't work Status in linux package in Ubuntu: Confirmed Bug description: Concatenating multiple initrds works fine with gzipped initrds. (microcode+gzip+gzip) => the kernel properly decompresses that With lz4, it can't decompress anything after the first lz4: (microcode+lz4+whatever) => it doesn't decompress whatever. To reproduce: Get vmlinuz and initrd.img from an eoan daily build and put them in a directory. Create an lz4 (or gzip or uncompressed cpio, it doesn't matter): # date > date.txt # echo date.txt | cpio -oH newc | lz4 > date.img Concatenate them: # cat initrd.img.original date.img > initrd.img Boot them: # kvm -m 512 -kernel vmlinuz -initrd initrd.img -append rdinit=/bin/sh Then inside kvm: # ls /date.txt The additional file doesn't exist. `dmesg | grep -i initramfs` reports: Trying to unpack rootfs image as initramfs... Initramfs unpacking failed: Decoding failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840945/+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 1840934] Re: Change kernel compression method to improve boot speed
Should we match these defaults for initramfs too? At the moment I have switched to lz4 across the board, but maybe it does make sense to use lzo on s390x and gzip on armhf, etc. Should I escalate to IBM supporting lz4 on ppc64le? -- 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/1840934 Title: Change kernel compression method to improve boot speed Status in linux package in Ubuntu: Fix Committed Bug description: Colin King has done some analysis of kernel boot speed using different kernel compression methods. Results for x86 are at: https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/boot-speed-compression-5.3-rc4.ods Testing of s390 gave the following: GZIP31528972 LZ4 192348049 LZO 85990145 From Colin: "I used the monotonic TOD timer using the stckf opcode to fetch a 64 bit time value. Not sure how this maps to 'real time' in seconds." Conclusion: We should switch x86 to LZ4 and s390 to LZO. PPC and ARM do not support LZO or LZ4, so we will stick with gzip there. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934/+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 1842050] [NEW] Please include DTBs for arm64 laptops
Public bug reported: Please include DTBs from qcom for-next tree: arm64: dts: qcom: Add Asus NovaGo TP370QL arm64: dts: qcom: Add HP Envy x2 arm64: dts: qcom: Add Lenovo Miix 630 https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h =for-next In foundations, we have Miix 630 and NovaGo available for testing. Currently desktop images are available from https://pskov.surgut.co.uk/bionic/daily-live/current/ Links to commits: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=722eb2f65acc4cebeb710fc7cc98f51513e90f1f https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3f527d311932791fde67ffec32536d22d5dd3030 https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=2c6d2d3a580a852fe0a694e13af502a862293e0e ** 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/1842050 Title: Please include DTBs for arm64 laptops Status in linux package in Ubuntu: Incomplete Bug description: Please include DTBs from qcom for-next tree: arm64: dts: qcom: Add Asus NovaGo TP370QL arm64: dts: qcom: Add HP Envy x2 arm64: dts: qcom: Add Lenovo Miix 630 https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h =for-next In foundations, we have Miix 630 and NovaGo available for testing. Currently desktop images are available from https://pskov.surgut.co.uk/bionic/daily-live/current/ Links to commits: https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=722eb2f65acc4cebeb710fc7cc98f51513e90f1f https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=3f527d311932791fde67ffec32536d22d5dd3030 https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=2c6d2d3a580a852fe0a694e13af502a862293e0e To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842050/+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 1817097] Re: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices
** Also affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New ** Changed in: lvm2 (Ubuntu) Status: Incomplete => Invalid ** Changed in: e2fsprogs (Ubuntu) Status: New => Fix Committed -- 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/1817097 Title: pvmove causes file system corruption without notice upon move from 512 -> 4096 logical block size devices Status in lvm2: Confirmed Status in Ubuntu on IBM z Systems: Incomplete Status in e2fsprogs package in Ubuntu: Fix Committed Status in linux package in Ubuntu: Invalid Status in lvm2 package in Ubuntu: Invalid Bug description: Problem Description--- Summary === Environment: IBM Z13 LPAR and z/VM Guest IBM Type: 2964 Model: 701 NC9 OS: Ubuntu 18.10 (GNU/Linux 4.18.0-13-generic s390x) Package: lvm2 version 2.02.176-4.1ubuntu3 LVM: pvmove operation corrupts file system when using 4096 (4k) logical block size and default block size being 512 bytes in the underlying devices The problem is immediately reproducible. We see a real usability issue with data destruction as consequence - which is not acceptable. We expect 'pvmove' to fail with error in such situations to prevent fs destruction, which might possibly be overridden by a force flag. Details === After a 'pvmove' operation is run to move a physical volume onto an ecrypted device with 4096 bytes logical block size we experience a file system corruption. There is no need for the file system to be mounted, but the problem surfaces differently if so. Either, the 'pvs' command after the pvmove shows /dev/LOOP_VG/LV: read failed after 0 of 1024 at 0: Invalid argument /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314507264: Invalid argument /dev/LOOP_VG/LV: read failed after 0 of 1024 at 314564608: Invalid argument /dev/LOOP_VG/LV: read failed after 0 of 1024 at 4096: Invalid argument or a subsequent mount shows (after umount if the fs had previously been mounted as in our setup) mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/LOOP_VG-LV, missing codepage or helper program, or other error. A minimal setup of LVM using one volume group with one logical volume defined, based on one physical volume is sufficient to raise the problem. One more physical volume of the same size is needed to run the pvmove operation to. LV | VG: LOOP_VG [ ] | PV: /dev/loop0 --> /dev/mapper/enc-loop ( backed by /dev/mapper/enc-loop ) The physical volumes are backed by loopback devices (losetup) to base the problem report on, but we have seen the error on real SCSI multipath volumes also, with and without cryptsetup mapper devices in use. Further discussion == https://www.saout.de/pipermail/dm-crypt/2019-February/006078.html The problem does not occur on block devices with native size of 4k. E.g. DASDs, or file systems with mkfs -b 4096 option. Terminal output === See attached file pvmove-error.txt Debug data == pvmove was run with -dd (maximum debug level) See attached journal file. Contact Information = christian.r...@de.ibm.com ---uname output--- Linux system 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:00:35 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = IBM Type: 2964 Model: 701 NC9 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1.) Create two image files of 500MB in size and set up two loopback devices with 'losetup -fP FILE' 2.) Create one physical volume and one volume group 'LOOP_VG', and one logical volume 'VG' Run: pvcreate /dev/loop0 vgcreate LOOP_VG /dev/loop0 lvcreate -L 300MB LOOP_VG -n LV /dev/loop0 3.) Create a file system on the logical volume device: mkfs.ext4 /dev/mapper/LOOP_VG-LV 4.) mount the file system created in the previous step to some empty available directory: mount /dev/mapper/LOOP_VG-LV /mnt 5.) Set up a second physical volume, this time encrypted with LUKS2, and open the volume to make it available: cryptsetup luksFormat --type luks2 --sector-size 4096 /dev/loop1 cryptsetup luksOpen /dev/loop1 enc-loop 6.) Create the second physical volume, and add it to the LOOP_VG pvcreate /dev/mapper/enc-loop vgextend LOOP_VG /dev/mapper/enc-loop 7.) Ensure the new physical volume is part of the volume group: pvs 8.) Move the /dev/loop0 volume onto the encrypted volume with maximum debug option: pvmove -dd /dev/loop0 /dev/mapper/enc-loop 9.) The previous step succeeds, but corrupts the file system on the logical volume We expect an error here. There might be a command l
[Kernel-packages] [Bug 1829749] [NEW] Please add support for zipl signing
Public bug reported:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
** Affects: launchpad
Importance: Undecided
Status: New
** Affects: linux-signed (Ubuntu)
Importance: Undecided
Status: New
** Affects: s390-tools (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux-signed (Ubuntu)
Importance: Undecided
Status: New
** Also affects: s390-tools (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
+
+ s390-tools -> can be signed already
+ kernels -> should only sign v5.2+
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1829749
Title:
Please add support for zipl signing
Status in Launchpad itself:
New
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
New
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
$ cat /boot/config-5.0.0-16-generic | grep LOG_BUF
CONFIG_LOG_BUF_SHIFT=18
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
$ uname -a
Linux doerfel 5.0.0-16-generic #17-Ubuntu SMP Wed May 15 10:54:19 UTC 2019
aarch64 aarch64 aarch64 GNU/Linux
And journal shows complete kernel boot messages, thus this all now good
on disco.
** Tags removed: verification-needed-disco
** Tags added: verification-done-disco
** No longer affects: systemd (Ubuntu Xenial)
** No longer affects: systemd (Ubuntu Bionic)
** No longer affects: systemd (Ubuntu Cosmic)
** No longer affects: systemd (Ubuntu Disco)
** No longer affects: systemd (Ubuntu Eoan)
** No longer affects: systemd (Ubuntu)
--
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/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Status in linux source package in Disco:
Fix Committed
Status in linux source package in Eoan:
Confirmed
Bug description:
[Impact]
* Too small dmsg kernel buf ring size leads to loosing/missing early
boot kernel messages which happen before journald starts slurping them
up and storing them on disc. This results in messages similar to this
one on boot "missed NN kernel messages on boot". This is especially
pronounced on arm64 as the default setting there is way lower than any
other 32bit or 64bit architecture we ship. Also amd64 appears to have
the highest setting of 18 among all architectures we ship. The best
course of action to bump all 64bit arches to 18, and keep all 32bit
arches at the current & upstream default of 17.
[Test Case]
* $ cat /boot/config-`uname -r` | grep CONFIG_LOG_BUF_SHIFT
on 64bit arches result should be: CONFIG_LOG_BUF_SHIFT=18
on 32bit arches result should be: CONFIG_LOG_BUF_SHIFT=17
* run systemd adt test, the boot-and-services test case should not
fail journald tests with "missed kernel messages" visible in the error
logs.
[Regression Potential]
* Increasing the size of the log_buf, will increase kernel memory
usage which cannot be reclaimed. It will now become 256kb on arm64,
ppc64el, s390x instead of 8kB/128kb/128kb respectively. 32bit arches
remain unchanged at 128kb.
[Other Info]
* Original bug report
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux
kernel command line in the dmesg (journalctl -k -b). And it is
consistently failing on arm64 scalingstack KVM EFI machines with
messages of "missing 81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
Please backport this to xenial and up.
=== systemd ===
systemd, boot-and-services test case can bump the ring buffer before
running the tests.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824864/+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 1829749] Re: Please add support for zipl signing
I do wonder, if we can somehow arch-specify opal signing.
Cause it's opal for power, zipl for s390x, yet both just use kmodsign.
Just a different key.
Not sure if i want to copy&paste all the methods, and tests.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1829749
Title:
Please add support for zipl signing
Status in Launchpad itself:
New
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
New
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1808056] Re: vmlinuz is very large in arm64 -raspi2
Can kernel team elaborate on this ticket? Cause as far as I can tell, we can change flash-kernel / boot.scr in eoan, and kernels do support compressed images on armhf And rewrite boot.scr on upgrade to eoan+ Is there something that I'm missing from shipping compressed kernels here? Something specific to armhf? arm64? ** Changed in: linux-raspi2 (Ubuntu) Status: Won't Fix => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi2 in Ubuntu. https://bugs.launchpad.net/bugs/1808056 Title: vmlinuz is very large in arm64 -raspi2 Status in flash-kernel package in Ubuntu: Confirmed Status in linux-raspi2 package in Ubuntu: Confirmed Bug description: The debs are close to the same size: mwhudson@ringil:~/Downloads$ ls -l linux-image-4.15.0-1030-raspi2_4.15.0-1030.32_arm64.deb -rw-rw-r-- 1 mwhudson mwhudson 5398652 Dec 12 10:42 linux-image-4.15.0-1030-raspi2_4.15.0-1030.32_arm64.deb mwhudson@ringil:~/Downloads$ ls -l linux-image-4.15.0-1030-raspi2_4.15.0-1030.32_armhf.deb -rw-rw-r-- 1 mwhudson mwhudson 6640960 Dec 12 10:42 linux-image-4.15.0-1030-raspi2_4.15.0-1030.32_armhf.deb But the vmlinuz on arm64 is several times larger: $ dpkg-deb -c linux-image-4.15.0-1030-raspi2_4.15.0-1030.32_armhf.deb -rw--- root/root 6633048 2018-12-07 06:38 ./boot/vmlinuz-4.15.0-1030-raspi2 $ dpkg-deb -c linux-image-4.15.0-1030-raspi2_4.15.0-1030.32_arm64.deb -rw--- root/root 23914504 2018-12-07 06:38 ./boot/vmlinuz-4.15.0-1030-raspi2 This forced us to make the boot partition larger for the raspi3 b+ arm64 image we made. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1808056/+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 1819882] [NEW] [CONFIG] please enable highdpi font FONT_TER16x32
Public bug reported: [CONFIG] please enable highdpi font FONT_TER16x32 This is now available in v5.0 config/config.common.ubuntu:# CONFIG_FONT_TER16x32 is not set https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/lib/fonts/Kconfig?id=ac8b6f148fc97e9e10b48bd337ef571b1d1136aa ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bot-stop-nagging -- 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/1819882 Title: [CONFIG] please enable highdpi font FONT_TER16x32 Status in linux package in Ubuntu: Incomplete Bug description: [CONFIG] please enable highdpi font FONT_TER16x32 This is now available in v5.0 config/config.common.ubuntu:# CONFIG_FONT_TER16x32 is not set https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/lib/fonts/Kconfig?id=ac8b6f148fc97e9e10b48bd337ef571b1d1136aa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819882/+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 1819881] [NEW] [CONFIG] please enable highdpi font FONT_TER16x32
Public bug reported: [CONFIG] please enable highdpi font FONT_TER16x32 This is now available in v5.0 config/config.common.ubuntu:# CONFIG_FONT_TER16x32 is not set https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/lib/fonts/Kconfig?id=ac8b6f148fc97e9e10b48bd337ef571b1d1136aa ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bot-stop-nagging -- 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/1819881 Title: [CONFIG] please enable highdpi font FONT_TER16x32 Status in linux package in Ubuntu: Incomplete Bug description: [CONFIG] please enable highdpi font FONT_TER16x32 This is now available in v5.0 config/config.common.ubuntu:# CONFIG_FONT_TER16x32 is not set https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/lib/fonts/Kconfig?id=ac8b6f148fc97e9e10b48bd337ef571b1d1136aa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819881/+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 1819881] Re: [CONFIG] please enable highdpi font FONT_TER16x32
I am in ecstasy! this is so good! OMG! My eyes! I love this! After installing your kernel, one needs to enable the font in console- setup too: $ cat /etc/default/console-setup | grep '^FONT' FONTFACE="TER" FONTSIZE="16x32" Then i did update-initramfs, and rebooted, and omg how nice my tty is now! If you can, please cherrypick this patch into all the GA kernels as far back as possible, if it like applies cleanly without too much trouble. Later, we will need to work on enabling console-setup (or maybe kernel?!) to autodetect and autopick TER 16x32. -- 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/1819881 Title: [CONFIG] please enable highdpi font FONT_TER16x32 Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Invalid Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Invalid Status in linux source package in Cosmic: Invalid Bug description: [CONFIG] please enable highdpi font FONT_TER16x32 This is now available in v5.0 config/config.common.ubuntu:# CONFIG_FONT_TER16x32 is not set https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/lib/fonts/Kconfig?id=ac8b6f148fc97e9e10b48bd337ef571b1d1136aa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819881/+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 1819881] Re: [CONFIG] please enable highdpi font FONT_TER16x32
Indeed, i booted the stock kernel with my new console-setup settings... and i get readable ttys still. And the config for your kernel did not appear to list 16x32 there either. Can you please share the source for the kernel you have built? Also I wonder where the TER 16x32 font is coming from, and how can we make it like the default on the Ubuntu Desktop. -- 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/1819881 Title: [CONFIG] please enable highdpi font FONT_TER16x32 Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: In Progress Bug description: [CONFIG] please enable highdpi font FONT_TER16x32 This is now available in v5.0 config/config.common.ubuntu:# CONFIG_FONT_TER16x32 is not set https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/lib/fonts/Kconfig?id=ac8b6f148fc97e9e10b48bd337ef571b1d1136aa To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1819881/+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 1822542] Re: All 12 tests in kvm-unit-test failed (timeouted) on X s390x KVM
nested kvm is disabled by default on s390x. One can force-enable that by booting with kernel cmdline kvm.nested=1 in /etc/zipl.conf and rerun $ sudo zipl; and reboot. However, I'm confused why this is filed, when this is the expected default behaviour and has been previously raised and discussed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1732162 Is there a testsuite expectation missmatch that expects nested-kvm by default, which is no longer provided by default? -- 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/1822542 Title: All 12 tests in kvm-unit-test failed (timeouted) on X s390x KVM Status in ubuntu-kernel-tests: New Status in linux package in Ubuntu: Incomplete Status in linux source package in Xenial: Incomplete Bug description: I think this bug is just a place holder, as the nested KVM is out-of- scope especially on s390x TESTNAME=selftest-setup TIMEOUT=90s ACCEL= ./s390x/run s390x/selftest.elf -smp 1 -append 'test 123' FAIL selftest-setup (timeout; duration=90s) TESTNAME=intercept TIMEOUT=90s ACCEL= ./s390x/run s390x/intercept.elf -smp 1 FAIL intercept (timeout; duration=90s) TESTNAME=emulator TIMEOUT=90s ACCEL= ./s390x/run s390x/emulator.elf -smp 1 FAIL emulator (timeout; duration=90s) TESTNAME=sieve TIMEOUT=600 ACCEL= ./s390x/run s390x/sieve.elf -smp 1 FAIL sieve (timeout; duration=600) TESTNAME=sthyi TIMEOUT=90s ACCEL= ./s390x/run s390x/sthyi.elf -smp 1 FAIL sthyi (timeout; duration=90s) TESTNAME=skey TIMEOUT=90s ACCEL= ./s390x/run s390x/skey.elf -smp 1 FAIL skey (timeout; duration=90s) TESTNAME=diag10 TIMEOUT=90s ACCEL= ./s390x/run s390x/diag10.elf -smp 1 FAIL diag10 (timeout; duration=90s) TESTNAME=pfmf TIMEOUT=90s ACCEL= ./s390x/run s390x/pfmf.elf -smp 1 FAIL pfmf (timeout; duration=90s) TESTNAME=cmm TIMEOUT=90s ACCEL= ./s390x/run s390x/cmm.elf -smp 1 FAIL cmm (timeout; duration=90s) TESTNAME=vector TIMEOUT=90s ACCEL= ./s390x/run s390x/vector.elf -smp 1 FAIL vector (timeout; duration=90s) TESTNAME=gs TIMEOUT=90s ACCEL= ./s390x/run s390x/gs.elf -smp 1 FAIL gs (timeout; duration=90s) TESTNAME=iep TIMEOUT=90s ACCEL= ./s390x/run s390x/iep.elf -smp 1 FAIL iep (timeout; duration=90s) ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-145-generic 4.4.0-145.171 ProcVersionSignature: Ubuntu 4.4.0-145.171-generic 4.4.176 Uname: Linux 4.4.0-145-generic s390x NonfreeKernelModules: zfs zunicode zcommon znvpair zavl 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' ApportVersion: 2.20.1-0ubuntu2.18 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found. CurrentDmesg: Date: Mon Apr 1 03:04:02 2019 HibernationDevice: RESUME=UUID=ca468a9c-9563-442c-85c6-6055e800a66e IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lsusb: Error: command ['lsusb'] failed with exit code 1: PciMultimedia: ProcFB: Error: [Errno 2] No such file or directory: '/proc/fb' ProcKernelCmdLine: root=UUID=b65b756a-ba4e-4c53-aa32-0db2bdb50bb3 crashkernel=196M RelatedPackageVersions: linux-restricted-modules-4.4.0-145-generic N/A linux-backports-modules-4.4.0-145-generic N/A linux-firmware 1.157.21 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1822542/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1831645] [NEW] [hint] linux-oracle 4.15.0-1014.16 FTBFS
Public bug reported: linux-oracle 4.15.0-1014.16 FTBFS http://autopkgtest.ubuntu.com/packages/l/linux-oracle/disco/amd64 Note that rebuild test is failing, blocking SRU of reverse-build dependency, as it appears as if openssl is breaking compiling linux- oracle. HOSTCC scripts/selinux/genheaders/genheaders In file included from /tmp/autopkgtest.QQNAdd/build.Tp6/src/scripts/selinux/genheaders/genheaders.c:19: /tmp/autopkgtest.QQNAdd/build.Tp6/src/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 [sru] Please fix linux-oracle kernel to be buildable from source in disco. [hint] Please commit disco-hint: force-badtest linux-oracle/4.15.0-1014.16 ** Affects: linux-oracle (Ubuntu) Importance: Critical Status: New ** Affects: linux-oracle (Ubuntu Cosmic) Importance: High Status: New ** Affects: linux-oracle (Ubuntu Disco) Importance: High Status: New ** Affects: linux-oracle (Ubuntu Eoan) Importance: Critical Status: New ** Tags: block-proposed ** Summary changed: - linux-oracle 4.15.0-1014.16 FTBFS + [hint] linux-oracle 4.15.0-1014.16 FTBFS -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1831645 Title: [hint] linux-oracle 4.15.0-1014.16 FTBFS Status in linux-oracle package in Ubuntu: New Status in linux-oracle source package in Cosmic: New Status in linux-oracle source package in Disco: New Status in linux-oracle source package in Eoan: New Bug description: linux-oracle 4.15.0-1014.16 FTBFS http://autopkgtest.ubuntu.com/packages/l/linux-oracle/disco/amd64 Note that rebuild test is failing, blocking SRU of reverse-build dependency, as it appears as if openssl is breaking compiling linux- oracle. HOSTCC scripts/selinux/genheaders/genheaders In file included from /tmp/autopkgtest.QQNAdd/build.Tp6/src/scripts/selinux/genheaders/genheaders.c:19: /tmp/autopkgtest.QQNAdd/build.Tp6/src/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 [sru] Please fix linux-oracle kernel to be buildable from source in disco. [hint] Please commit disco-hint: force-badtest linux-oracle/4.15.0-1014.16 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1831645/+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 1831645] Re: [hint] linux-oracle 4.15.0-1014.16 FTBFS
Possibly duplicate bug reports: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1823429 https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1826993 ** Changed in: linux-oracle (Ubuntu) Importance: Undecided => High ** Changed in: linux-oracle (Ubuntu) Importance: High => Critical ** Tags added: block-proposed ** Also affects: linux-oracle (Ubuntu Eoan) Importance: Critical Status: New ** Also affects: linux-oracle (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux-oracle (Ubuntu Cosmic) Importance: Undecided Status: New ** Tags added: rls-ee-incoming -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1831645 Title: [hint] linux-oracle 4.15.0-1014.16 FTBFS Status in linux-oracle package in Ubuntu: New Status in linux-oracle source package in Cosmic: New Status in linux-oracle source package in Disco: New Status in linux-oracle source package in Eoan: New Bug description: linux-oracle 4.15.0-1014.16 FTBFS http://autopkgtest.ubuntu.com/packages/l/linux-oracle/disco/amd64 Note that rebuild test is failing, blocking SRU of reverse-build dependency, as it appears as if openssl is breaking compiling linux- oracle. HOSTCC scripts/selinux/genheaders/genheaders In file included from /tmp/autopkgtest.QQNAdd/build.Tp6/src/scripts/selinux/genheaders/genheaders.c:19: /tmp/autopkgtest.QQNAdd/build.Tp6/src/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 [sru] Please fix linux-oracle kernel to be buildable from source in disco. [hint] Please commit disco-hint: force-badtest linux-oracle/4.15.0-1014.16 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1831645/+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 1831645] Re: [hint] linux-oracle 4.15.0-1014.16 FTBFS
It is not acceptable to build linux-oracle in bionic, copy it up into all releases, when it cannot be rebuilt in any later series, for 3 cycles now. is linux-oracle be indefinately be built on bionic? ** Changed in: linux-oracle (Ubuntu Disco) Importance: Undecided => High ** Changed in: linux-oracle (Ubuntu Cosmic) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1831645 Title: [hint] linux-oracle 4.15.0-1014.16 FTBFS Status in linux-oracle package in Ubuntu: New Status in linux-oracle source package in Cosmic: New Status in linux-oracle source package in Disco: New Status in linux-oracle source package in Eoan: New Bug description: linux-oracle 4.15.0-1014.16 FTBFS http://autopkgtest.ubuntu.com/packages/l/linux-oracle/disco/amd64 Note that rebuild test is failing, blocking SRU of reverse-build dependency, as it appears as if openssl is breaking compiling linux- oracle. HOSTCC scripts/selinux/genheaders/genheaders In file included from /tmp/autopkgtest.QQNAdd/build.Tp6/src/scripts/selinux/genheaders/genheaders.c:19: /tmp/autopkgtest.QQNAdd/build.Tp6/src/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 [sru] Please fix linux-oracle kernel to be buildable from source in disco. [hint] Please commit disco-hint: force-badtest linux-oracle/4.15.0-1014.16 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1831645/+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 1831645] Re: [hint] linux-oracle 4.15.0-1014.16 FTBFS
Currently blocking 3 SRUs requiring manual analysis and intervention from uploaders and the SRU team. Also, it is a questionable quality kernel if it cannot be compiled on any later series. ** Tags removed: rls-ee-incoming -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1831645 Title: [hint] linux-oracle 4.15.0-1014.16 FTBFS Status in linux-oracle package in Ubuntu: New Status in linux-oracle source package in Cosmic: New Status in linux-oracle source package in Disco: New Status in linux-oracle source package in Eoan: New Bug description: linux-oracle 4.15.0-1014.16 FTBFS http://autopkgtest.ubuntu.com/packages/l/linux-oracle/disco/amd64 Note that rebuild test is failing, blocking SRU of reverse-build dependency, as it appears as if openssl is breaking compiling linux- oracle. HOSTCC scripts/selinux/genheaders/genheaders In file included from /tmp/autopkgtest.QQNAdd/build.Tp6/src/scripts/selinux/genheaders/genheaders.c:19: /tmp/autopkgtest.QQNAdd/build.Tp6/src/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 [sru] Please fix linux-oracle kernel to be buildable from source in disco. [hint] Please commit disco-hint: force-badtest linux-oracle/4.15.0-1014.16 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1831645/+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
Re: [Kernel-packages] [Bug 1823429] Re: linux-oracle ftbfs in disco
It's up to the kernel team to manage kernel bugs. Are you linux-oracle maintainer? On Tue, 4 Jun 2019, 21:35 Dan Streetman, wrote: > This is difficult because security/selinux/ doesn't use the *actual* > kernel headers for the kernel being built to get the AF_MAX/PF_MAX defines; > those are not included in the kernel uapi headers. Instead, those defines > come from /usr/include/x86_64-linux-gnu/bits/socket.h which is provided by: > $ dpkg -S bits/socket.h > libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/socket.h > > -- > You received this bug notification because you are subscribed to a > duplicate bug report (1831645). > https://bugs.launchpad.net/bugs/1823429 > > Title: > linux-oracle ftbfs in disco > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1823429/+subscriptions > -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1823429 Title: linux-oracle ftbfs in disco Status in linux-oracle package in Ubuntu: Confirmed Bug description: https://launchpadlibrarian.net/417924791/buildlog_ubuntu-disco-amd64 .linux-oracle_4.15.0-1010.12_BUILDING.txt.gz HOSTLD scripts/mod/modpost HOSTCC scripts/selinux/genheaders/genheaders In file included from /<>/scripts/selinux/genheaders/genheaders.c:19: /<>/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 make[5]: *** [/<>/scripts/Makefile.build:606: scripts/selinux/genheaders] Error 2 make[4]: *** [/<>/scripts/Makefile.build:606: scripts/selinux] Error 2 make[3]: *** [/<>/Makefile:589: scripts] Error 2 make[2]: *** [/<>/Makefile:278: __build_one_by_one] Error 2 make[2]: Leaving directory '/<>/debian/build/build-oracle' make[1]: *** [Makefile:146: sub-make] Error 2 make[1]: Leaving directory '/<>' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1823429/+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 1823429] Re: linux-oracle ftbfs in disco
** Tags added: block-proposed rls-ee-incoming -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1823429 Title: linux-oracle ftbfs in disco Status in linux-oracle package in Ubuntu: Confirmed Bug description: https://launchpadlibrarian.net/417924791/buildlog_ubuntu-disco-amd64 .linux-oracle_4.15.0-1010.12_BUILDING.txt.gz HOSTLD scripts/mod/modpost HOSTCC scripts/selinux/genheaders/genheaders In file included from /<>/scripts/selinux/genheaders/genheaders.c:19: /<>/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 make[5]: *** [/<>/scripts/Makefile.build:606: scripts/selinux/genheaders] Error 2 make[4]: *** [/<>/scripts/Makefile.build:606: scripts/selinux] Error 2 make[3]: *** [/<>/Makefile:589: scripts] Error 2 make[2]: *** [/<>/Makefile:278: __build_one_by_one] Error 2 make[2]: Leaving directory '/<>/debian/build/build-oracle' make[1]: *** [Makefile:146: sub-make] Error 2 make[1]: Leaving directory '/<>' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/1823429/+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 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
Well, it's "better" but still failing. http://autopkgtest.ubuntu.com/packages/systemd/eoan/ppc64el ** Changed in: systemd (Ubuntu Eoan) Status: Fix Released => Confirmed -- 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/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Committed Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Confirmed Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+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 1831736] [NEW] [MIR] lz4 by default
Public bug reported: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: live-build (Ubuntu) Importance: Undecided Status: New ** Affects: livecd-rootfs (Ubuntu) Importance: Undecided Status: New ** Affects: lz4 (Ubuntu) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu) Importance: Undecided Status: New ** Also affects: live-build (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Summary changed: - lz4 by default + [MIR] lz4 by default ** Also affects: lz4 (Ubuntu) Importance: Undecided Status: New ** Description changed: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. + This would also pull the lz4 package into main + https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html -- 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/1831736 Title: [MIR] lz4 by default Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in live-build package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: New Status in lz4 package in Ubuntu: New Bug description: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1831736] Re: [MIR] lz4 by default
** Changed in: lz4 (Ubuntu) Status: New => Confirmed ** Changed in: initramfs-tools (Ubuntu) Status: New => Fix Committed ** Changed in: live-build (Ubuntu) Status: New => Fix Committed -- 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/1831736 Title: [MIR] lz4 by default Status in initramfs-tools package in Ubuntu: Fix Committed Status in linux package in Ubuntu: Incomplete Status in live-build package in Ubuntu: Fix Committed Status in livecd-rootfs package in Ubuntu: New Status in lz4 package in Ubuntu: Confirmed Bug description: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1831736] Re: [MIR] lz4 by default
** Changed in: livecd-rootfs (Ubuntu) Status: New => Fix Committed -- 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/1831736 Title: [MIR] lz4 by default Status in initramfs-tools package in Ubuntu: Fix Committed Status in linux package in Ubuntu: Incomplete Status in live-build package in Ubuntu: Fix Committed Status in livecd-rootfs package in Ubuntu: Fix Committed Status in lz4 package in Ubuntu: Confirmed Bug description: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1831232] Re: Ubuntu 18.04 won't boot - failed to connect to lvmetad
Can you boot with old initrd from the boot menu options? Can you unlock things by-hand from the initramfs shell, and continue the boot by exiting the shell? What is the expected layout of things that should be done? And what are the contents of /etc/crypttab /etc/fstab ? ** Changed in: lvm2 (Ubuntu) Status: New => Incomplete ** Changed in: linux (Ubuntu) Status: Confirmed => 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/1831232 Title: Ubuntu 18.04 won't boot - failed to connect to lvmetad Status in linux package in Ubuntu: Incomplete Status in lvm2 package in Ubuntu: Incomplete Bug description: This bug report relates to a machine running 18.04, not the one I am submitting the report from. On 30 May The Software Updater prompted me to update. Included in the update were initramfs components. I now cannot boot the machine. After decrypting the root file system, instead of being prompted for the pass-phrase to decrypt the swap, I get the message "cannot connect to lvmetad: falling back to device scanning". This repeats for a while until I am dropped into a recovery shell of some sort from which I cannot access the root disk. Blocker. My machine is unusable. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: linux-generic 4.15.0.48.50 ProcVersionSignature: Ubuntu 4.15.0-48.51-generic 4.15.18 Uname: Linux 4.15.0-48-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: gdm2433 F pulseaudio raph 8920 F pulseaudio /dev/snd/controlC0: gdm2433 F pulseaudio Date: Fri May 31 12:08:33 2019 HibernationDevice: RESUME=UUID=2538baa4-d43e-4876-8d94-dd3221894bac InstallationDate: Installed on 2018-02-09 (475 days ago) InstallationMedia: Xubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) MachineType: LENOVO 20CJS0UU00 ProcEnviron: LANGUAGE=en_GB:en TERM=xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-48-generic root=/dev/mapper/xubuntu--vg-root ro quiet splash vt.handoff=1 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-4.15.0-48-generic N/A linux-backports-modules-4.15.0-48-generic N/A linux-firmware 1.173.5 SourcePackage: linux UpgradeStatus: Upgraded to bionic on 2018-09-12 (260 days ago) dmi.bios.date: 09/13/2017 dmi.bios.vendor: LENOVO dmi.bios.version: N11ET42W (1.18 ) dmi.board.asset.tag: Not Available dmi.board.name: 20CJS0UU00 dmi.board.vendor: LENOVO dmi.board.version: SDK0E50510 WIN dmi.chassis.asset.tag: R90G3N7R dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN11ET42W(1.18):bd09/13/2017:svnLENOVO:pn20CJS0UU00:pvrThinkPadT550:rvnLENOVO:rn20CJS0UU00:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T550 dmi.product.name: 20CJS0UU00 dmi.product.version: ThinkPad T550 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831232/+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 1823429] Re: linux v4.15 ftbfs on a newer host kernel (e.g. hwe)
** Summary changed: - linux-oracle ftbfs in disco + linux v4.15 ftbfs on a newer host kernel (e.g. hwe) ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Description changed: + [Impact] + + * linux v4.15.x fails to build on newer host machine kernels (i.e. hwe / +v4.18+ ) + + [Fix] + + * Instead of relying on a potentially incompatible host system/kernel + definitions of PF_MAX, use the one from the source tree. + + * Upstream commit: + + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=master&id=dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e + + which was cherrypicked to stable as: + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=145f6a70bb9b422a6df5fb8b9408046151f3e4f9 + + [Test Case] + + * Install linux-hwe kernel, reboot, try to rebuild linux GA kernel. + + [Regression Potential] + + * This is a FTBFS fix only, to use matching definitions from the target + kernel at build time. + + [Other Info] + + * Original bug report, autopkgtest regression rebuild test case of the bionic's linux-oracle kernel on newer host kernels: + https://launchpadlibrarian.net/417924791/buildlog_ubuntu-disco-amd64 .linux-oracle_4.15.0-1010.12_BUILDING.txt.gz - HOSTLD scripts/mod/modpost - HOSTCC scripts/selinux/genheaders/genheaders + HOSTLD scripts/mod/modpost + HOSTCC scripts/selinux/genheaders/genheaders In file included from /<>/scripts/selinux/genheaders/genheaders.c:19: /<>/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. - #error New address family defined, please update secclass_map. - ^ + #error New address family defined, please update secclass_map. + ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 make[5]: *** [/<>/scripts/Makefile.build:606: scripts/selinux/genheaders] Error 2 make[4]: *** [/<>/scripts/Makefile.build:606: scripts/selinux] Error 2 make[3]: *** [/<>/Makefile:589: scripts] Error 2 make[2]: *** [/<>/Makefile:278: __build_one_by_one] Error 2 make[2]: Leaving directory '/<>/debian/build/build-oracle' make[1]: *** [Makefile:146: sub-make] Error 2 make[1]: Leaving directory '/<>' ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux-oracle (Ubuntu Bionic) Importance: Undecided Status: New ** Description changed: [Impact] - * linux v4.15.x fails to build on newer host machine kernels (i.e. hwe / -v4.18+ ) + * linux v4.15.x fails to build on newer host machine kernels (i.e. hwe / + v4.18+ ) [Fix] - * Instead of relying on a potentially incompatible host system/kernel + * Instead of relying on a potentially incompatible host system/kernel definitions of PF_MAX, use the one from the source tree. - * Upstream commit: + * Upstream commit in v5.1-rc1-2-gdfbd199a7cfe: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=master&id=dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e which was cherrypicked to stable as: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=145f6a70bb9b422a6df5fb8b9408046151f3e4f9 [Test Case] - * Install linux-hwe kernel, reboot, try to rebuild linux GA kernel. + * Install linux-hwe kernel, reboot, try to rebuild linux GA kernel. [Regression Potential] - * This is a FTBFS fix only, to use matching definitions from the target + * This is a FTBFS fix only, to use matching definitions from the target kernel at build time. [Other Info] - - * Original bug report, autopkgtest regression rebuild test case of the bionic's linux-oracle kernel on newer host kernels: + + * Original bug report, autopkgtest regression rebuild test case of the + bionic's linux-oracle kernel on newer host kernels: https://launchpadlibrarian.net/417924791/buildlog_ubuntu-disco-amd64 .linux-oracle_4.15.0-1010.12_BUILDING.txt.gz HOSTLD scripts/mod/modpost HOSTCC scripts/selinux/genheaders/genheaders In file included from /<>/scripts/selinux/genheaders/genheaders.c:19: /<>/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 make[5]: *** [/<>/scripts/Makefile.build:606: scripts/selinux/genheaders] Error 2 make[4]: *** [/<>/scripts/Makefile.build:606: scripts/selinux] Error 2 make[3]: *** [/<>/Makefile:589: scripts] Error 2 make[2]: *** [/<>/Makefile:278: __build_one_by_one] Error 2 make[2]: Leaving directory '/<>/debian/build/build-oracle' make[1]: *** [Makefile:146: sub-make] Error 2 make[1]: Leaving directory '/<>' -- You received this bug notification because you are a member o
[Kernel-packages] [Bug 1823429] Re: linux v4.15 ftbfs on a newer host kernel (e.g. hwe)
** Description changed: [Impact] * linux v4.15.x fails to build on newer host machine kernels (i.e. hwe / v4.18+ ) [Fix] * Instead of relying on a potentially incompatible host system/kernel definitions of PF_MAX, use the one from the source tree. * Upstream commit in v5.1-rc1-2-gdfbd199a7cfe: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=master&id=dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e which was cherrypicked to stable as: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=145f6a70bb9b422a6df5fb8b9408046151f3e4f9 + + Submitted to the kernel team mailing list (whilst spamming too many people in CC) at + https://lists.ubuntu.com/archives/kernel-team/2019-June/101190.html [Test Case] * Install linux-hwe kernel, reboot, try to rebuild linux GA kernel. [Regression Potential] * This is a FTBFS fix only, to use matching definitions from the target kernel at build time. [Other Info] * Original bug report, autopkgtest regression rebuild test case of the bionic's linux-oracle kernel on newer host kernels: https://launchpadlibrarian.net/417924791/buildlog_ubuntu-disco-amd64 .linux-oracle_4.15.0-1010.12_BUILDING.txt.gz HOSTLD scripts/mod/modpost HOSTCC scripts/selinux/genheaders/genheaders In file included from /<>/scripts/selinux/genheaders/genheaders.c:19: /<>/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 make[5]: *** [/<>/scripts/Makefile.build:606: scripts/selinux/genheaders] Error 2 make[4]: *** [/<>/scripts/Makefile.build:606: scripts/selinux] Error 2 make[3]: *** [/<>/Makefile:589: scripts] Error 2 make[2]: *** [/<>/Makefile:278: __build_one_by_one] Error 2 make[2]: Leaving directory '/<>/debian/build/build-oracle' make[1]: *** [Makefile:146: sub-make] Error 2 make[1]: Leaving directory '/<>' ** Tags removed: block-proposed rls-cc-incoming rls-dd-incoming rls-ee-incoming ** Tags added: bot-stop-naging ** Changed in: linux (Ubuntu Bionic) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-oracle in Ubuntu. https://bugs.launchpad.net/bugs/1823429 Title: linux v4.15 ftbfs on a newer host kernel (e.g. hwe) Status in linux package in Ubuntu: Confirmed Status in linux-oracle package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Status in linux-oracle source package in Bionic: New Bug description: [Impact] * linux v4.15.x fails to build on newer host machine kernels (i.e. hwe / v4.18+ ) [Fix] * Instead of relying on a potentially incompatible host system/kernel definitions of PF_MAX, use the one from the source tree. * Upstream commit in v5.1-rc1-2-gdfbd199a7cfe: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=master&id=dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e which was cherrypicked to stable as: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=145f6a70bb9b422a6df5fb8b9408046151f3e4f9 Submitted to the kernel team mailing list (whilst spamming too many people in CC) at https://lists.ubuntu.com/archives/kernel-team/2019-June/101190.html [Test Case] * Install linux-hwe kernel, reboot, try to rebuild linux GA kernel. [Regression Potential] * This is a FTBFS fix only, to use matching definitions from the target kernel at build time. [Other Info] * Original bug report, autopkgtest regression rebuild test case of the bionic's linux-oracle kernel on newer host kernels: https://launchpadlibrarian.net/417924791/buildlog_ubuntu-disco-amd64 .linux-oracle_4.15.0-1010.12_BUILDING.txt.gz HOSTLD scripts/mod/modpost HOSTCC scripts/selinux/genheaders/genheaders In file included from /<>/scripts/selinux/genheaders/genheaders.c:19: /<>/security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^ make[6]: *** [scripts/Makefile.host:90: scripts/selinux/genheaders/genheaders] Error 1 make[5]: *** [/<>/scripts/Makefile.build:606: scripts/selinux/genheaders] Error 2 make[4]: *** [/<>/scripts/Makefile.build:606: scripts/selinux] Error 2 make[3]: *** [/<>/Makefile:589: scripts] Error 2 make[2]: *** [/<>/Makefile:278: __build_one_by_one] Error 2 make[2]: Leaving directory '/<>/debian/build/build-oracle' make[1]: *** [Makefile:146: sub-make] Error 2 make[1]: Leaving directory '/<>' To manage notifications about
[Kernel-packages] [Bug 1831736] Re: [MIR] lz4 by default
** Changed in: lz4 (Ubuntu) Status: Confirmed => Fix Released ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- 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/1831736 Title: [MIR] lz4 by default Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Confirmed Status in live-build package in Ubuntu: Fix Released Status in livecd-rootfs package in Ubuntu: Fix Released Status in lz4 package in Ubuntu: Fix Released Status in partman-auto package in Ubuntu: Triaged Status in ubuntu-release-upgrader package in Ubuntu: Triaged Bug description: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1831736] Re: [MIR] lz4 by default
** Description changed: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html + + [Regression Potential] + + We are trying to optimize for total boot speed, but performing a micro- + optimization upon time to create/unpack kernel/initrd is an insufficient + benchmark for total boot speed. This is because it ignores time to load + the kernel/initrd, and whether the firmware/bootloader were able to + stream decompress it whilst loading it. I.e. it is argued that in the + real world, subsecond decompression gains are irrelevant if UEFI + firmware, tftp boot, etc. take a lot longer than that to read extra 10s + of MBs of boot material. + + [TODO] + Measure pure i/o load speed with stopwatch, to figure out MB/s speed of loading initrds/kernel off FAT32, EXT4, TFTP, HTTP. + Re-evaluate if we should provide different compression mechanisms: + - ie. gzip instead of lz4 for most cases (revert) + - ie. xz for painful i/o cases (e.g. netboot) -- 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/1831736 Title: [MIR] lz4 by default Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Confirmed Status in live-build package in Ubuntu: Fix Released Status in livecd-rootfs package in Ubuntu: Fix Released Status in lz4 package in Ubuntu: Fix Released Status in partman-auto package in Ubuntu: Triaged Status in ubuntu-release-upgrader package in Ubuntu: Triaged Bug description: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html [Regression Potential] We are trying to optimize for total boot speed, but performing a micro-optimization upon time to create/unpack kernel/initrd is an insufficient benchmark for total boot speed. This is because it ignores time to load the kernel/initrd, and whether the firmware/bootloader were able to stream decompress it whilst loading it. I.e. it is argued that in the real world, subsecond decompression gains are irrelevant if UEFI firmware, tftp boot, etc. take a lot longer than that to read extra 10s of MBs of boot material. [TODO] Measure pure i/o load speed with stopwatch, to figure out MB/s speed of loading initrds/kernel off FAT32, EXT4, TFTP, HTTP. Re-evaluate if we should provide different compression mechanisms: - ie. gzip instead of lz4 for most cases (revert) - ie. xz for painful i/o cases (e.g. netboot) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1831736] Re: [MIR] lz4 by default
** Description changed: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html [Regression Potential] We are trying to optimize for total boot speed, but performing a micro- optimization upon time to create/unpack kernel/initrd is an insufficient benchmark for total boot speed. This is because it ignores time to load the kernel/initrd, and whether the firmware/bootloader were able to stream decompress it whilst loading it. I.e. it is argued that in the real world, subsecond decompression gains are irrelevant if UEFI firmware, tftp boot, etc. take a lot longer than that to read extra 10s of MBs of boot material. [TODO] Measure pure i/o load speed with stopwatch, to figure out MB/s speed of loading initrds/kernel off FAT32, EXT4, TFTP, HTTP. Re-evaluate if we should provide different compression mechanisms: - ie. gzip instead of lz4 for most cases (revert) - ie. xz for painful i/o cases (e.g. netboot) + + I booted grub2 and measured loading largish amount of files, ie. $ date; + initrd (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd + (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd + (hd0,gpt5)/initrd.img; date + + To get a rough speed between 30 and 44 MB/s of loading these files off + ext4 on nvme. + + With lz4 initrd taking 67M, and gzip initrd taking 59M, the grub i/o + penalty is 0.18s whilst I gain over a second in faster decompression + time. Overall a win. + + xz initrd is 36M meaning saving e.g. 0.8s of i/o time whilst gaining + 2.4s of decompression time, meaning overall worse than gzip. -- 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/1831736 Title: [MIR] lz4 by default Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: Confirmed Status in live-build package in Ubuntu: Fix Released Status in livecd-rootfs package in Ubuntu: Fix Released Status in lz4 package in Ubuntu: Fix Released Status in partman-auto package in Ubuntu: Triaged Status in ubuntu-release-upgrader package in Ubuntu: Triaged Bug description: Use `lz4 -9 -l` compression for initramfs by default as discussed on ubuntu-devel. This would also pull the lz4 package into main https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html [Regression Potential] We are trying to optimize for total boot speed, but performing a micro-optimization upon time to create/unpack kernel/initrd is an insufficient benchmark for total boot speed. This is because it ignores time to load the kernel/initrd, and whether the firmware/bootloader were able to stream decompress it whilst loading it. I.e. it is argued that in the real world, subsecond decompression gains are irrelevant if UEFI firmware, tftp boot, etc. take a lot longer than that to read extra 10s of MBs of boot material. [TODO] Measure pure i/o load speed with stopwatch, to figure out MB/s speed of loading initrds/kernel off FAT32, EXT4, TFTP, HTTP. Re-evaluate if we should provide different compression mechanisms: - ie. gzip instead of lz4 for most cases (revert) - ie. xz for painful i/o cases (e.g. netboot) I booted grub2 and measured loading largish amount of files, ie. $ date; initrd (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; date To get a rough speed between 30 and 44 MB/s of loading these files off ext4 on nvme. With lz4 initrd taking 67M, and gzip initrd taking 59M, the grub i/o penalty is 0.18s whilst I gain over a second in faster decompression time. Overall a win. xz initrd is 36M meaning saving e.g. 0.8s of i/o time whilst gaining 2.4s of decompression time, meaning overall worse than gzip. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1792189] Re: linux-firmware does not depend on initramfs-tools
I.e. instead of the current $ cat debian/linux-firmware.postinst #!/bin/sh set -e if [ -x /usr/sbin/update-initramfs ]; then /usr/sbin/update-initramfs -u -k all fi #DEBHELPER# It should do instead $ cat cat debian/linux-firmware.triggers activate-noawait update-initramfs ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => Won't Fix ** Also affects: linux-firmware (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-firmware in Ubuntu. https://bugs.launchpad.net/bugs/1792189 Title: linux-firmware does not depend on initramfs-tools Status in initramfs-tools package in Ubuntu: Won't Fix Status in linux-firmware package in Ubuntu: New Bug description: In bug #1646197 the linux-firmware.postinst was added to call update- initramfs (provided by initramfs-tools. If the initramfs-tools package is not installed the installation of linux-firmware will fail. Recreate: sudo apt-get purge --assume-yes '^linux-.*' 'linux-base+' initramfs* sudo apt-get install --assume-yes linux-generic Result: Setting up linux-modules-4.15.0-34-generic (4.15.0-34.37) ... Setting up linux-headers-4.15.0-34 (4.15.0-34.37) ... Setting up linux-headers-4.15.0-34-generic (4.15.0-34.37) ... Setting up initramfs-tools-bin (0.130ubuntu3.3) ... Setting up linux-firmware (1.173.1) ... update-initramfs: Generating /boot/initrd.img-4.15.0-1021-kvm /usr/sbin/mkinitramfs: 66: .: Can't open /etc/initramfs-tools/initramfs.conf update-initramfs: failed for /boot/initrd.img-4.15.0-1021-kvm with 2. dpkg: error processing package linux-firmware (--configure): installed linux-firmware package post-installation script subprocess returned error exit status 2 ... Errors were encountered while processing: linux-firmware linux-image-generic linux-generic E: Sub-process /usr/bin/dpkg returned an error code (1) Impact: Builds of minimized images start with an image that has the linux-kvm kernel but lack initramfs-tools. Derivative builds that require a different kernel, linux-generic for example, will purge the existing kernel and install the correct kernel which could pull in linux-firmware and initramfs-tools. In that case the builds fail unless initramfs-tools is installed prior to kernel installation as a workaround for this missing package dependency. This has been recreated on cosmic and bionic, a fix is desired on each. (I was unable to recreate on Xenial but that package lacks the dependency as well). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1792189/+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 1783961] Re: CONFIG_KVM is disabled for linux-raspi2 (aarch64)
** Changed in: linux-raspi2 (Ubuntu) Assignee: (unassigned) => Dimitri John Ledkov (xnox) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi2 in Ubuntu. https://bugs.launchpad.net/bugs/1783961 Title: CONFIG_KVM is disabled for linux-raspi2 (aarch64) Status in linux-raspi2 package in Ubuntu: Confirmed Bug description: In contrast to the Linux kernel for x86_64, the CONFIG_KVM option is disabled for the "linux-raspi2" kernel (version 4.15.0-1016-raspi2 aarch64) on Ubuntu 18.04. This prevents running QEMU with the -enable-kvm option to use hardware virtualization capabilities of the CPU. I have recompiled the kernel with CONFIG_KVM set and could successfully run QEMU with -enable-kvm on my Raspberry Pi 3 B+ afterwards. In my opinion, there is no reason for not activating CONFIG_KVM in the official raspi2 kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1783961/+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 1829749] Re: Please add support for zipl signing
tested s390-tools packages on dogfood which look correct.
** Changed in: s390-tools (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1829749
Title:
Please add support for zipl signing
Status in Launchpad itself:
Fix Committed
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
In Progress
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1829749] Re: Please add support for zipl signing
** Changed in: s390-tools (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1829749
Title:
Please add support for zipl signing
Status in Launchpad itself:
Fix Released
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
Fix Committed
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1829749] Re: Please add support for zipl signing
s390-tools in UNAPPROVED
https://launchpad.net/ubuntu/eoan/+queue?queue_state=1&queue_text=s390-tools
s390-tools-signed in source NEW
https://launchpad.net/ubuntu/eoan/+queue?queue_state=0&queue_text=s390-tools-signed
** Summary changed:
- Please add support for zipl signing
+ Please add support for sipl
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1829749
Title:
Please add support for sipl
Status in Launchpad itself:
Fix Released
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
Fix Committed
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1829749] Re: [MIR] Please add support for SIPL
** Summary changed:
- Please add support for SIPL
+ [MIR] Please add support for SIPL
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1829749
Title:
[MIR] Please add support for SIPL
Status in Launchpad itself:
Fix Released
Status in linux-signed package in Ubuntu:
New
Status in s390-tools package in Ubuntu:
Fix Committed
Status in s390-tools-signed package in Ubuntu:
Fix Released
Bug description:
Please add support for zipl ("z/ecureBoot") signing.
It should be similar to opal signing, but using the new zipl signing
key.
I am expecting to sign s390-tools stage3.bin and kernel images using
this key.
s390-tools -> can be signed already
kernels -> should only sign v5.2+
To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad/+bug/1829749/+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 1776631] Re: [19.04 FEAT] I/O device pre-configuration
** Changed in: subiquity Status: Incomplete => Fix Released ** Changed in: ubuntu-z-systems Status: In Progress => Fix Released -- 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/1776631 Title: [19.04 FEAT] I/O device pre-configuration Status in subiquity: Invalid Status in Ubuntu on IBM z Systems: Fix Released Status in debian-installer package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in s390-tools package in Ubuntu: Fix Released Bug description: I/O device auto-configuration is a mechanism by which users can specify IDs and settings of I/O devices that should be automatically enabled in Linux. Users enter this information for an LPAR via an HMC running in DPM mode. During boot, Linux obtains this information via an SCLP call (details to be defined) and triggers the resulting configuration actions (e.g. using the chzdev command). Available with kernel 4.17 To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1776631/+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 1776631] Re: [19.04 FEAT] I/O device pre-configuration
** Changed in: subiquity Status: Fix Released => Invalid -- 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/1776631 Title: [19.04 FEAT] I/O device pre-configuration Status in subiquity: Invalid Status in Ubuntu on IBM z Systems: Fix Released Status in debian-installer package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in s390-tools package in Ubuntu: Fix Released Bug description: I/O device auto-configuration is a mechanism by which users can specify IDs and settings of I/O devices that should be automatically enabled in Linux. Users enter this information for an LPAR via an HMC running in DPM mode. During boot, Linux obtains this information via an SCLP call (details to be defined) and triggers the resulting configuration actions (e.g. using the chzdev command). Available with kernel 4.17 To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1776631/+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 1824864] Re: CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
** Description changed:
+ [Impact]
+
+ * Too small dmsg kernel buf ring size leads to loosing/missing early
+ boot kernel messages which happen before journald starts slurping them
+ up and storing them on disc. This results in messages similar to this
+ one on boot "missed NN kernel messages on boot". This is especially
+ pronounced on arm64 as the default setting there is way lower than any
+ other 32bit or 64bit architecture we ship. Also amd64 appears to have
+ the highest setting of 18 among all architectures we ship. The best
+ course of action to bump all 64bit arches to 18, and keep all 32bit
+ arches at the current & upstream default of 17.
+
+ [Test Case]
+
+ * $ cat /boot/config-`uname -r` | grep CONFIG_LOG_BUF_SHIFT
+
+ on 64bit arches result should be: CONFIG_LOG_BUF_SHIFT=18
+ on 32bit arches result should be: CONFIG_LOG_BUF_SHIFT=17
+
+ * run systemd adt test, the boot-and-services test case should not fail
+ journald tests with "missed kernel messages" visible in the error logs.
+
+ [Regression Potential]
+
+ * Increasing the size of the log_buf, will increase kernel memory usage
+ which cannot be reclaimed. It will now become 256kb on arm64, ppc64el,
+ s390x instead of 8kB/128kb/128kb respectively. 32bit arches remain
+ unchanged at 128kb.
+
+ [Other Info]
+
+ * Original bug report
+
CONFIG_LOG_BUF_SHIFT
policy<{
'amd64' : '18',
'arm64' : '14',
'armhf' : '17',
'i386' : '17',
'ppc64el': '17',
's390x' : '17'}>
Please set CONFIG_LOG_BUF_SHIFT to at least 17 on arm64.
Potentially bump all 64-bit arches to 18 (or higher!) as was done on
amd64, meaning set 18 on arm64 s390x ppc64el.
I have a systemd autopkgtest test that asserts that we see Linux kernel
command line in the dmesg (journalctl -k -b). And it is consistently
failing on arm64 scalingstack KVM EFI machines with messages of "missing
81 kernel messages".
config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
range 12 25
default 17
depends on PRINTK
help
Select the minimal kernel log buffer size as a power of 2.
The final size is affected by LOG_CPU_MAX_BUF_SHIFT config
parameter, see below. Any higher size also might be forced
by "log_buf_len" boot parameter.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB
14 sounds like redictiously low for arm64. given that 17 is default
across 32-bit arches, and 18 is default on amd64.
On a related note, we have CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT
policy<{'amd64': '13', 'arm64': '13', 'armhf': '13', 'i386': '13', 'ppc64el':
'13', 's390x': '13'}>
I'm not sure if we want to bump these up to LOG_BUF_SHIFT size or not.
Please backport this to xenial and up.
-
-
=== systemd ===
systemd, boot-and-services test case can bump the ring buffer before
running the tests.
--
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/1824864
Title:
CONFIG_LOG_BUF_SHIFT set to 14 is too low on arm64
Status in linux package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
New
Status in linux source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
New
Status in linux source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
New
Status in linux source package in Cosmic:
Confirmed
Status in systemd source package in Cosmic:
New
Status in linux source package in Disco:
Confirmed
Status in systemd source package in Disco:
New
Status in linux source package in Eoan:
Confirmed
Status in systemd source package in Eoan:
New
Bug description:
[Impact]
* Too small dmsg kernel buf ring size leads to loosing/missing early
boot kernel messages which happen before journald starts slurping them
up and storing them on disc. This results in messages similar to this
one on boot "missed NN kernel messages on boot". This is especially
pronounced on arm64 as the default setting there is way lower than any
other 32bit or 64bit architecture we ship. Also amd64 appears to have
the highest setting of 18 among all architectures we ship. The best
course of action to bump all 64bit arches to 18, and keep all 32bit
arches at the current & upstream default of 17.
[Test Case]
* $ cat /boot/config-`uname -r` | grep CONFIG_LOG_BUF_SHIFT
on 64bit arches result should be: CONFIG_LOG_BUF_SHIFT=18
on 32bit arches result should be: CONFIG_LOG_BUF_SHIFT=17
* run systemd adt test, the boot-and-services test case should not
fail journald tests with "missed kernel messages" visible in the error
logs.
[Regression Potential]
[Kernel-packages] [Bug 1823056] Re: autopkgtests run too often, too much and don't skip enough
Requesting to rerun linux test cases, as triggered by gcc-8 to confirm the fix. As currently they pass rebuild test, but end up as an overall FAIL due to regression suite. they should turn green under: http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#gcc-8 Or look for gree pass, as triggered by gcc-8 on https://autopkgtest.ubuntu.com/packages/linux/cosmic/s390x -- 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/1823056 Title: autopkgtests run too often, too much and don't skip enough Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] * linux autopkgtest should only execute either rebuild tests, when triggered by toolchain. or execute regression suite when triggered by meta but never both. As otherwise, it results in false negative results for the kernel [Test Case] * Trigger adt test of linux with a matching linux-meta. Check that rebuild test is skipped, and that the regression suite test runs. * trigger adt test of linux with triggered by gcc-6/7/8 (as appropriate) and observe that rebuild test runs, and regression suite test is skipped. * (when this is applied to flavours) trigger adt test of linux-* with a matching flavour meta, and check that regression test-suite is skipped on kernels that cannot boot in scaling stack (e.g. gcp, azure, aws, etc) [Fix] * debian/tests/* are modified to pay more attention as to what they are triggered by, and raise appropriate skipped error codes [Regression Potential] * incorrect tests may run at incorrect time is the regression potential here, hence the two test cases verify that the right tests are executed when expected. * care was taken to take into account all linux kernel flavours, hence the third test case need to be reverified on flavoured kernels. [Other Info] * affects all stable series xenial and up, across all kernel flavours To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056/+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 1823056] Re: autopkgtests run too often, too much and don't skip enough
https://people.canonical.com/~ubuntu-archive/proposed- migration/cosmic/update_excuses.html#gcc-8 all is now green, and checking the results one can see that rebuild test passed, and the regression test suite was skipped, correctly. Great stuff. ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1823056 Title: autopkgtests run too often, too much and don't skip enough Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] * linux autopkgtest should only execute either rebuild tests, when triggered by toolchain. or execute regression suite when triggered by meta but never both. As otherwise, it results in false negative results for the kernel [Test Case] * Trigger adt test of linux with a matching linux-meta. Check that rebuild test is skipped, and that the regression suite test runs. * trigger adt test of linux with triggered by gcc-6/7/8 (as appropriate) and observe that rebuild test runs, and regression suite test is skipped. * (when this is applied to flavours) trigger adt test of linux-* with a matching flavour meta, and check that regression test-suite is skipped on kernels that cannot boot in scaling stack (e.g. gcp, azure, aws, etc) [Fix] * debian/tests/* are modified to pay more attention as to what they are triggered by, and raise appropriate skipped error codes [Regression Potential] * incorrect tests may run at incorrect time is the regression potential here, hence the two test cases verify that the right tests are executed when expected. * care was taken to take into account all linux kernel flavours, hence the third test case need to be reverified on flavoured kernels. [Other Info] * affects all stable series xenial and up, across all kernel flavours To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056/+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 1823056] Re: autopkgtests run too often, too much and don't skip enough
Triggering for example linux adt test in bionic, as triggered by openssl to verify the fix. -- 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/1823056 Title: autopkgtests run too often, too much and don't skip enough Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] * linux autopkgtest should only execute either rebuild tests, when triggered by toolchain. or execute regression suite when triggered by meta but never both. As otherwise, it results in false negative results for the kernel [Test Case] * Trigger adt test of linux with a matching linux-meta. Check that rebuild test is skipped, and that the regression suite test runs. * trigger adt test of linux with triggered by gcc-6/7/8 (as appropriate) and observe that rebuild test runs, and regression suite test is skipped. * (when this is applied to flavours) trigger adt test of linux-* with a matching flavour meta, and check that regression test-suite is skipped on kernels that cannot boot in scaling stack (e.g. gcp, azure, aws, etc) [Fix] * debian/tests/* are modified to pay more attention as to what they are triggered by, and raise appropriate skipped error codes [Regression Potential] * incorrect tests may run at incorrect time is the regression potential here, hence the two test cases verify that the right tests are executed when expected. * care was taken to take into account all linux kernel flavours, hence the third test case need to be reverified on flavoured kernels. [Other Info] * affects all stable series xenial and up, across all kernel flavours To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056/+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 1823056] Re: autopkgtests run too often, too much and don't skip enough
http://autopkgtest.ubuntu.com/packages/l/linux/bionic/amd64 and it passed. Works as expected. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1823056 Title: autopkgtests run too often, too much and don't skip enough Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Cosmic: Fix Committed Bug description: [Impact] * linux autopkgtest should only execute either rebuild tests, when triggered by toolchain. or execute regression suite when triggered by meta but never both. As otherwise, it results in false negative results for the kernel [Test Case] * Trigger adt test of linux with a matching linux-meta. Check that rebuild test is skipped, and that the regression suite test runs. * trigger adt test of linux with triggered by gcc-6/7/8 (as appropriate) and observe that rebuild test runs, and regression suite test is skipped. * (when this is applied to flavours) trigger adt test of linux-* with a matching flavour meta, and check that regression test-suite is skipped on kernels that cannot boot in scaling stack (e.g. gcp, azure, aws, etc) [Fix] * debian/tests/* are modified to pay more attention as to what they are triggered by, and raise appropriate skipped error codes [Regression Potential] * incorrect tests may run at incorrect time is the regression potential here, hence the two test cases verify that the right tests are executed when expected. * care was taken to take into account all linux kernel flavours, hence the third test case need to be reverified on flavoured kernels. [Other Info] * affects all stable series xenial and up, across all kernel flavours To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056/+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 1838258] Re: Unable to configure VLAN on an additional OSA interface
What's the output of: $ ip a ? Also matching dmesg / syslog / journal? -- 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/1838258 Title: Unable to configure VLAN on an additional OSA interface Status in Ubuntu on IBM z Systems: Triaged Status in iproute2 package in Ubuntu: New Status in linux package in Ubuntu: New Bug description: After installing a base Ubuntu 18.04.1 server, an additional OSA device "e530" is attached and configured with chzdev. Then a VLAN configuration should be applied using the ip command. However this results in the error message "RTNETLINK answers: File exists". >snip ip link add link ence530 name ence530.209 type vlan id 209 RTNETLINK answers: File exists snip< Executing the same steps on an Ubuntu 16.04.5 server, the ip command finishes without an error message but the VLAN interface is also not configured. Reproduction: - Install a 18.04.1 server - attach an additional OSA interface - configure a VLAN using the ip command To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1838258/+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 1839622] [NEW] enable lockdown on s390x when Secure IPL is performed
Public bug reported: s390x support secureboot via secure IPL mechanism. When booted with Secure IPL, lock-down should be enabled. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1839622 Title: enable lockdown on s390x when Secure IPL is performed Status in linux package in Ubuntu: New Bug description: s390x support secureboot via secure IPL mechanism. When booted with Secure IPL, lock-down should be enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1839622/+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 1839622] Re: enable lockdown on s390x when Secure IPL is performed
** Tags added: bot-stop-nagging ** Changed in: linux (Ubuntu) Status: Incomplete => Triaged -- 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/1839622 Title: enable lockdown on s390x when Secure IPL is performed Status in linux package in Ubuntu: Triaged Bug description: s390x support secureboot via secure IPL mechanism. When booted with Secure IPL, lock-down should be enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1839622/+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 1862749] Re: [UBUNTU 20.04] Thin Provisioning support (disablement or final solution)
In eoan we shipped: 57d53162face UBUNTU: SAUCE: Revert "s390/dasd: Add discard support for ESE volumes" And as it is a SAUCE patch, we continue to ship it, as we don't implicitely drop them: 964ce509e2de Revert "s390/dasd: Add discard support for ESE volumes" Currently if you grep for DASD_FEATURE_DISCARD: $ git grep DASD_FEATURE_DISCARD arch/s390/include/uapi/asm/dasd.h:#define DASD_FEATURE_DISCARD0x080 drivers/s390/block/dasd_fba.c: dasd_set_feature(cdev, DASD_FEATURE_DISCARD, 1); It is only enabled for the FBA devices. Since the original request to disable DISCARD for ESE volumes, we have not re-enabled them. So what is the purporse of this request? Do you want us to disable it for FBA volumes too? We will not re-enable DISCARD for ESE volumes, until you say it's good again. -- 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/1862749 Title: [UBUNTU 20.04] Thin Provisioning support (disablement or final solution) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: This pro-active fix is requested to provide the code for disablement of Thin Provisioning within Ubuntu 20.04, like within Ubuntu 19.10 or providing the final solution from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1862749/+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 1862749] Re: [UBUNTU 20.04] Thin Provisioning support (disablement or final solution)
Ok, I see that either https://lists.ubuntu.com/archives/kernel- team/2020-January/107107.html needs to land in unstable & focal kernel trees, or better thing-provisioning support. -- 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/1862749 Title: [UBUNTU 20.04] Thin Provisioning support (disablement or final solution) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: This pro-active fix is requested to provide the code for disablement of Thin Provisioning within Ubuntu 20.04, like within Ubuntu 19.10 or providing the final solution from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1862749/+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 1862255] Re: focal/linux-5.4: 5.4.0-14.17 -proposed tracker
Can I have it as a snap please? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-5.4 in Ubuntu. https://bugs.launchpad.net/bugs/1862255 Title: focal/linux-5.4: 5.4.0-14.17 -proposed tracker Status in Kernel SRU Workflow: Fix Released Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-release series: Fix Released Status in Kernel SRU Workflow regression-testing series: Fix Released Status in linux-5.4 package in Ubuntu: Fix Released Status in linux-5.4 source package in Focal: Fix Released Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true packages: lrm: linux-restricted-modules-5.4 main: linux-5.4 meta: linux-meta-5.4 signed: linux-signed-5.4 phase: Complete phase-changed: Thursday, 13. February 2020 21:41 UTC proposed-announcement-sent: true proposed-testing-requested: true trackers: focal/linux-5.4/pc-kernel: bug 1862243, bug 1862245 focal/linux-5.4/pc-lowlatency-kernel: bug 1862246, bug 1862244 focal/linux-azure-5.4: bug 1862250 focal/linux-gcp-5.4: bug 1862252 focal/linux-kvm-5.4: bug 1862253 focal/linux-oem-5.4: bug 1862249 focal/linux-oracle-5.4: bug 1862254 focal/linux-raspi2-5.4: bug 1862248 variant: debs To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1862255/+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 1835660] Re: initramfs unpacking failed
We currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => Invalid ** Description changed: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. + + --- + + However, we currently believe that the decoding error reported in dmesg + is actually harmless and has no impact on usability on the system. + + Switching from lz4 to gzip compression, simply papers over the warning, + without any benefits, and slows down boot. + + Kernel should be fixed to correctly parse lz4 compressed initrds, or at + least lower the warning, to not be user visible as an error. -- 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/1835660 Title: initramfs unpacking failed Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+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 1871611] [NEW] multipath nvme, failed to install with multipath disabled install failed crashed with CalledProcessError
Public bug reported:
multipath nvme, failed to install with multipath disabled install failed
crashed with CalledProcessError
so trying to install with nvme_core.multipath=0 set on the cmdline, and that
fails.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: subiquity (1641)
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic ppc64le
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu24
Architecture: ppc64el
CasperVersion: 1.443
CrashDB:
{
"impl": "launchpad",
"project": "subiquity",
"bug_pattern_url":
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml";
}
Date: Wed Apr 8 11:35:20 2020
ExecutablePath: /snap/subiquity/1638/usr/bin/subiquity
InstallerLog: Error: [Errno 2] No such file or directory: 'logfile'
InterpreterPath: /snap/subiquity/1638/usr/bin/python3.6
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta ppc64el (20200408)
Lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1d6b:0107 Linux Foundation USB Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ProcAttrCurrent: snap.subiquity.subiquity (complain)
ProcCmdline: /snap/subiquity/1638/usr/bin/python3
/snap/subiquity/1638/usr/bin/subiquity
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: ip=dhcp
url=http://cdimage.ubuntu.com/hostname/daily-live/pending/focal-live-server-ppc64el.iso
subiquity-channel=latest/edge nvme_core.multipath=0
http_proxy=http://91.189.89.11:3128 --- quiet
ProcLoadAvg: 0.11 1.05 0.96 1/1380 14592
ProcLocks:
1: FLOCK ADVISORY WRITE 5503 00:18:751 0 EOF
2: POSIX ADVISORY WRITE 5198 00:18:647 0 EOF
3: POSIX ADVISORY WRITE 5520 00:18:760 0 EOF
ProcSwaps: Filename TypeSizeUsed
Priority
ProcVersion: Linux version 5.4.0-21-generic (buildd@bos02-ppc64el-028) (gcc
version 9.3.0 (Ubuntu 9.3.0-8ubuntu1)) #25-Ubuntu SMP Sat Mar 28 13:10:37 UTC
2020
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal,
3.8.2-0ubuntu2
PythonDetails: N/A
SnapChannel:
SnapRevision: 1638
SnapUpdated: False
SnapVersion: 20.03.3+git132.a0dae13d
SourcePackage: subiquity
Title: install failed crashed with CalledProcessError
UpgradeStatus: No upgrade log present (probably fresh install)
UsingAnswers: False
VarLogDump_list: total 0
cpu_cores: Number of cores present = 32
cpu_coreson: Number of cores online = 32
cpu_smt: SMT=4
** Affects: curtin
Importance: Undecided
Status: New
** Affects: subiquity
Importance: Undecided
Status: New
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Confirmed
** Tags: apport-bug apport-hook-error focal ppc64el uec-images
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Information type changed from Private to Public
--
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/1871611
Title:
multipath nvme, failed to install with multipath disabled install
failed crashed with CalledProcessError
Status in curtin:
New
Status in subiquity:
New
Status in linux package in Ubuntu:
Confirmed
Bug description:
multipath nvme, failed to install with multipath disabled install
failed crashed with CalledProcessError
so trying to install with nvme_core.multipath=0 set on the cmdline, and that
fails.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: subiquity (1641)
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic ppc64le
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu24
Architecture: ppc64el
CasperVersion: 1.443
CrashDB:
{
"impl": "launchpad",
"project": "subiquity",
"bug_pattern_url":
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml";
}
Date: Wed Apr 8 11:35:20 2020
ExecutablePath: /snap/subiquity/1638/usr/bin/subiquity
InstallerLog: Error: [Errno 2] No such file or directory: 'logfile'
InterpreterPath: /snap/subiquity/1638/usr/bin/python3.6
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta ppc64el
(20200408)
Lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1d6b:0107 Linux Foundation USB Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ProcAttrCurrent: snap.subiquity.subiquity (complain)
ProcCmdline: /snap/subiquity/1638/usr/bin/python3
/snap/subiquity/1638/usr/bin/subiquity
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: ip=dhcp
url=http://cdimage.ubuntu.com/hostname/daily-live/pending/focal-live-server-ppc64el.
[Kernel-packages] [Bug 1871611] Re: multipath nvme, failed to install with multipath disabled install failed crashed with CalledProcessError
/dev/nvme0* is now gone, yet still mounted as /target. Yeap this is
borken.
--
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/1871611
Title:
multipath nvme, failed to install with multipath disabled install
failed crashed with CalledProcessError
Status in curtin:
New
Status in subiquity:
New
Status in linux package in Ubuntu:
Confirmed
Bug description:
multipath nvme, failed to install with multipath disabled install
failed crashed with CalledProcessError
so trying to install with nvme_core.multipath=0 set on the cmdline, and that
fails.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: subiquity (1641)
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic ppc64le
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu24
Architecture: ppc64el
CasperVersion: 1.443
CrashDB:
{
"impl": "launchpad",
"project": "subiquity",
"bug_pattern_url":
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml";
}
Date: Wed Apr 8 11:35:20 2020
ExecutablePath: /snap/subiquity/1638/usr/bin/subiquity
InstallerLog: Error: [Errno 2] No such file or directory: 'logfile'
InterpreterPath: /snap/subiquity/1638/usr/bin/python3.6
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta ppc64el
(20200408)
Lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1d6b:0107 Linux Foundation USB Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ProcAttrCurrent: snap.subiquity.subiquity (complain)
ProcCmdline: /snap/subiquity/1638/usr/bin/python3
/snap/subiquity/1638/usr/bin/subiquity
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: ip=dhcp
url=http://cdimage.ubuntu.com/hostname/daily-live/pending/focal-live-server-ppc64el.iso
subiquity-channel=latest/edge nvme_core.multipath=0
http_proxy=http://91.189.89.11:3128 --- quiet
ProcLoadAvg: 0.11 1.05 0.96 1/1380 14592
ProcLocks:
1: FLOCK ADVISORY WRITE 5503 00:18:751 0 EOF
2: POSIX ADVISORY WRITE 5198 00:18:647 0 EOF
3: POSIX ADVISORY WRITE 5520 00:18:760 0 EOF
ProcSwaps: Filename TypeSizeUsed
Priority
ProcVersion: Linux version 5.4.0-21-generic (buildd@bos02-ppc64el-028) (gcc
version 9.3.0 (Ubuntu 9.3.0-8ubuntu1)) #25-Ubuntu SMP Sat Mar 28 13:10:37 UTC
2020
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal,
3.8.2-0ubuntu2
PythonDetails: N/A
SnapChannel:
SnapRevision: 1638
SnapUpdated: False
SnapVersion: 20.03.3+git132.a0dae13d
SourcePackage: subiquity
Title: install failed crashed with CalledProcessError
UpgradeStatus: No upgrade log present (probably fresh install)
UsingAnswers: False
VarLogDump_list: total 0
cpu_cores: Number of cores present = 32
cpu_coreson: Number of cores online = 32
cpu_smt: SMT=4
To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1871611/+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 1871611] Re: multipath nvme, failed to install with multipath disabled install failed crashed with CalledProcessError
Looks like with nvme_core.multipath=0 nvme install still fails.
** Also affects: curtin
Importance: Undecided
Status: New
--
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/1871611
Title:
multipath nvme, failed to install with multipath disabled install
failed crashed with CalledProcessError
Status in curtin:
New
Status in subiquity:
New
Status in linux package in Ubuntu:
Confirmed
Bug description:
multipath nvme, failed to install with multipath disabled install
failed crashed with CalledProcessError
so trying to install with nvme_core.multipath=0 set on the cmdline, and that
fails.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: subiquity (1641)
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic ppc64le
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu24
Architecture: ppc64el
CasperVersion: 1.443
CrashDB:
{
"impl": "launchpad",
"project": "subiquity",
"bug_pattern_url":
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml";
}
Date: Wed Apr 8 11:35:20 2020
ExecutablePath: /snap/subiquity/1638/usr/bin/subiquity
InstallerLog: Error: [Errno 2] No such file or directory: 'logfile'
InterpreterPath: /snap/subiquity/1638/usr/bin/python3.6
LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta ppc64el
(20200408)
Lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1d6b:0107 Linux Foundation USB Virtual Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ProcAttrCurrent: snap.subiquity.subiquity (complain)
ProcCmdline: /snap/subiquity/1638/usr/bin/python3
/snap/subiquity/1638/usr/bin/subiquity
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: ip=dhcp
url=http://cdimage.ubuntu.com/hostname/daily-live/pending/focal-live-server-ppc64el.iso
subiquity-channel=latest/edge nvme_core.multipath=0
http_proxy=http://91.189.89.11:3128 --- quiet
ProcLoadAvg: 0.11 1.05 0.96 1/1380 14592
ProcLocks:
1: FLOCK ADVISORY WRITE 5503 00:18:751 0 EOF
2: POSIX ADVISORY WRITE 5198 00:18:647 0 EOF
3: POSIX ADVISORY WRITE 5520 00:18:760 0 EOF
ProcSwaps: Filename TypeSizeUsed
Priority
ProcVersion: Linux version 5.4.0-21-generic (buildd@bos02-ppc64el-028) (gcc
version 9.3.0 (Ubuntu 9.3.0-8ubuntu1)) #25-Ubuntu SMP Sat Mar 28 13:10:37 UTC
2020
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal,
3.8.2-0ubuntu2
PythonDetails: N/A
SnapChannel:
SnapRevision: 1638
SnapUpdated: False
SnapVersion: 20.03.3+git132.a0dae13d
SourcePackage: subiquity
Title: install failed crashed with CalledProcessError
UpgradeStatus: No upgrade log present (probably fresh install)
UsingAnswers: False
VarLogDump_list: total 0
cpu_cores: Number of cores present = 32
cpu_coreson: Number of cores online = 32
cpu_smt: SMT=4
To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1871611/+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 1866852] Re: System Display black screen on reboot or after a clean shutdown with USB-C Dock Monitor
i wonder if usb-hub can reproduce it. -- 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/1866852 Title: System Display black screen on reboot or after a clean shutdown with USB-C Dock Monitor Status in grub2 package in Ubuntu: Confirmed Status in linux package in Ubuntu: Invalid Status in grub2 source package in Focal: Confirmed Status in linux source package in Focal: Invalid Bug description: I'm running focal devel and the latest kernel (see proc version below) Linux version 5.4.0-18-generic (buildd@lgw01-amd64-034) (gcc version 9.2.1 20200306 (Ubuntu 9.2.1-31ubuntu3)) #22-Ubuntu SMP Sat Mar 7 18:13:06 UTC 2020 Dock Monitor is supported very well with multiple usb devices plugged on the monitor. However on reboot I face a black screen with no ability to enter my FDE password. Both my Laptop screen and the attached usb-c display nothing I have to hard power off and reboot without the USB-C monitor plugged in. Otherwise A reboot cycle with the usb-c unplugged works perfectly. Also I tried to run ubuntu-bug linux or ubuntu-bug linux-image-generic without success. I would be happy to provide much more debugging information. I will attach then to the launchpad Bug # --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu18 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: mclemenceau 2988 F pulseaudio /dev/snd/controlC0: mclemenceau 2988 F pulseaudio /dev/snd/controlC1: mclemenceau 2988 F pulseaudio CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 20.04 InstallationDate: Installed on 2020-01-05 (64 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: HP HP Spectre x360 Convertible 13-ae0xx NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-18-generic root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 RelatedPackageVersions: linux-restricted-modules-5.4.0-18-generic N/A linux-backports-modules-5.4.0-18-generic N/A linux-firmware1.186 Tags: focal Uname: Linux 5.4.0-18-generic x86_64 UpgradeStatus: Upgraded to focal on 2020-01-23 (47 days ago) UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 06/14/2018 dmi.bios.vendor: AMI dmi.bios.version: F.21 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 83B9 dmi.board.vendor: HP dmi.board.version: 56.41 dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAMI:bvrF.21:bd06/14/2018:svnHP:pnHPSpectrex360Convertible13-ae0xx:pvr:rvnHP:rn83B9:rvr56.41:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Spectre dmi.product.name: HP Spectre x360 Convertible 13-ae0xx dmi.product.sku: 2TV18AS#ABA dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1866852/+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 1837525] Re: [20.04 FEAT] Set Architecture Level (ALS) to z13
Due to a bug in gcc-9 (default version) packaging, it has been configured in focal with both march & mtune set to z13. And gcc-9 will remain configured this way in focal (20.04). At this point we don't have enough time for a full archive rebuild with mtune set to z15, and majority of distribution binaries will not be rebuild at this point and are final. Meaning an update to z15 will only have impact on security & SRU packages. Changing mtune in all focal SRUs & security updates increases risk of any update regressing or failing to build from source. We can SRU individual packages to build with mtune z15 if there is significant performance improvement from doing so. Linux Kernel & atlas are correctly built with mtune z15 in focal. focal (20.04) will have non-default gcc-10 updated to use march z13 & mtune z15. GG-series (20.10) will have the default gcc version updated to use march z13 & mtune z15. ** Also affects: gcc-10 (Ubuntu) Importance: Undecided Status: New -- 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/1837525 Title: [20.04 FEAT] Set Architecture Level (ALS) to z13 Status in Ubuntu on IBM z Systems: Fix Released Status in atlas package in Ubuntu: Fix Released Status in gcc-10 package in Ubuntu: New Status in gcc-9 package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: IBM requests to update the Architecture Level Set (ALS) as follow.. march=z13 mtune=z15 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1837525/+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 1872941] Re: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed
The URL is changed intentionally, to notify all users that these images are deprecated and will not be updated after 20.04.0 GA, and will no longer be published in the future. You should not be using virt-install, and simply boot the s390x cloud- image in-place, with suitable cloud-config drive attached. This way, you simply directly boot into installed ubuntu server, which executes cloud- init and reconfigures the instance on first boot as desired without performing installation & reboot. If you want to test the installer, please use the new installer interactively or with auto-install config provided as a cloud-config drive as mentioned on the download page itself http://ports.ubuntu.com/dists/focal/main/installer-s390x/current/legacy- images/ We felt that we had to rename and change URLs, to notify all automated systems that these images are going away. This communication / notification mechanism seems to be working as intended. Because it broke your current 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/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in virt-manager package in Ubuntu: New Bug description: Installer version: Latest https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x Description/Reproduction: Start virt-install with the following options: virt-install \ --name ubuntu20-guest1 \ --memory 4096 \ --vcpus 4 \ --disk "size=4" \ --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \ --network "network=default" Error: ERRORError validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x' The location must be the root directory of an install tree. See virt-install man page for various distro examples. Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution. == Comment: #2 - Andre Wild1 - 2020-04-15 03:51:21 == (In reply to comment #0) > Installer version: Latest > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x > Sorry I've copied the wrong link. This is the link I've used successfully in the past: http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1872941/+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 1872941] Re: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed
** Also affects: ubuntu-cdimage Importance: Undecided Status: New ** Changed in: ubuntu-cdimage Status: New => Opinion ** Changed in: virt-manager (Ubuntu) Status: New => Invalid -- 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/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed Status in Ubuntu CD Images: Opinion Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in virt-manager package in Ubuntu: Invalid Bug description: Installer version: Latest https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x Description/Reproduction: Start virt-install with the following options: virt-install \ --name ubuntu20-guest1 \ --memory 4096 \ --vcpus 4 \ --disk "size=4" \ --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \ --network "network=default" Error: ERRORError validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x' The location must be the root directory of an install tree. See virt-install man page for various distro examples. Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution. == Comment: #2 - Andre Wild1 - 2020-04-15 03:51:21 == (In reply to comment #0) > Installer version: Latest > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x > Sorry I've copied the wrong link. This is the link I've used successfully in the past: http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1872941/+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 1872941] Re: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed
Renaming the artefacts was a compromise. the other option was to not publish them at all. d-i artefacts will not exist for 20.10 release, nor for 20.04.1 release, on any architecture. Thus renamed d-i artefacts is a transitional period of ~3 months until 20.04.1 is released. cloud-images for s390x with working cloud-init existed since the pre- release of the very first s390x architecture build. And work with xenial, bionic, and focal, and all intermediate releases. Why is using cloud-images not suitable for your test team which works for all Ubuntu s390x releases, and are pre-built and refreshed for every new kernel SRU? Unlike the d-i based images which are only refreshed every 6 months? https://cloud-images.ubuntu.com/ are genuinely more up to date, and are quicker to provision than d-i based installs. There are tested/curated release streams with ~2-3 week cadence, and daily streams which are updated ~1-3 days, with all packages up to date from the first boot. Can we help you move away from virt-instal d-i, to booting cloud images with any configuration applied on first-boot with cloud-init? -- 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/1872941 Title: [Ubuntu 20.04] virt-install fails to detect path after images folder name has changed Status in Ubuntu CD Images: Opinion Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in virt-manager package in Ubuntu: Invalid Bug description: Installer version: Latest https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x Description/Reproduction: Start virt-install with the following options: virt-install \ --name ubuntu20-guest1 \ --memory 4096 \ --vcpus 4 \ --disk "size=4" \ --location http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x \ --network "network=default" Error: ERRORError validating install location: Could not find an installable distribution at 'http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x' The location must be the root directory of an install tree. See virt-install man page for various distro examples. Looking at previous releases I would guess it expects an "images" directory instead of the new "classic-images" directory. I'm aware of the workaround to specify kernel/initramfs directly but that shouldn't be a solution. == Comment: #2 - Andre Wild1 - 2020-04-15 03:51:21 == (In reply to comment #0) > Installer version: Latest > https://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x > Sorry I've copied the wrong link. This is the link I've used successfully in the past: http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-s390x To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1872941/+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 1873838] Re: Purging Kernels leaves stuff behind
never midn i had extras & headers left over ** Changed in: linux (Ubuntu) Status: New => Invalid -- 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/1873838 Title: Purging Kernels leaves stuff behind Status in linux package in Ubuntu: Invalid Bug description: I've purged kernels Some directories were not removed because they were non-empty $ du -a ls 5.4.0-1* du: cannot access 'ls': No such file or directory 216 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.order 8 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.builtin 125.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.builtin.bin 240 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem 244 5.4.0-1002-oem/usr/lib/modules 248 5.4.0-1002-oem/usr/lib 252 5.4.0-1002-oem/usr 0 5.4.0-1002-oem/lib 256 5.4.0-1002-oem 0 5.4.0-14-generic/build 4 5.4.0-14-generic 264 5.4.0-16-generic/modules.symbols 312 5.4.0-16-generic/modules.symbols.bin 152 5.4.0-16-generic/modules.alias.bin 4 5.4.0-16-generic/modules.softdep 4 5.4.0-16-generic/modules.devname 845.4.0-16-generic/modules.dep 125.4.0-16-generic/modules.builtin.bin 120 5.4.0-16-generic/modules.dep.bin 144 5.4.0-16-generic/modules.alias 285.4.0-16-generic/modules.builtin.alias.bin 1128 5.4.0-16-generic 264 5.4.0-17-generic/modules.symbols 312 5.4.0-17-generic/modules.symbols.bin 152 5.4.0-17-generic/modules.alias.bin 4 5.4.0-17-generic/modules.softdep 4 5.4.0-17-generic/modules.devname 845.4.0-17-generic/modules.dep 125.4.0-17-generic/modules.builtin.bin 120 5.4.0-17-generic/modules.dep.bin 144 5.4.0-17-generic/modules.alias 285.4.0-17-generic/modules.builtin.alias.bin 1128 5.4.0-17-generic 264 5.4.0-18-generic/modules.symbols 312 5.4.0-18-generic/modules.symbols.bin 152 5.4.0-18-generic/modules.alias.bin 4 5.4.0-18-generic/modules.softdep 4 5.4.0-18-generic/modules.devname 845.4.0-18-generic/modules.dep 125.4.0-18-generic/modules.builtin.bin 120 5.4.0-18-generic/modules.dep.bin 144 5.4.0-18-generic/modules.alias 285.4.0-18-generic/modules.builtin.alias.bin 1128 5.4.0-18-generic Seems like we don't clean up enough of modules.* things on purge? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873838/+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 1873838] [NEW] Purging Kernels leaves stuff behind
Public bug reported: I've purged kernels Some directories were not removed because they were non-empty $ du -a ls 5.4.0-1* du: cannot access 'ls': No such file or directory 216 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.order 8 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.builtin 12 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.builtin.bin 240 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem 244 5.4.0-1002-oem/usr/lib/modules 248 5.4.0-1002-oem/usr/lib 252 5.4.0-1002-oem/usr 0 5.4.0-1002-oem/lib 256 5.4.0-1002-oem 0 5.4.0-14-generic/build 4 5.4.0-14-generic 264 5.4.0-16-generic/modules.symbols 312 5.4.0-16-generic/modules.symbols.bin 152 5.4.0-16-generic/modules.alias.bin 4 5.4.0-16-generic/modules.softdep 4 5.4.0-16-generic/modules.devname 84 5.4.0-16-generic/modules.dep 12 5.4.0-16-generic/modules.builtin.bin 120 5.4.0-16-generic/modules.dep.bin 144 5.4.0-16-generic/modules.alias 28 5.4.0-16-generic/modules.builtin.alias.bin 11285.4.0-16-generic 264 5.4.0-17-generic/modules.symbols 312 5.4.0-17-generic/modules.symbols.bin 152 5.4.0-17-generic/modules.alias.bin 4 5.4.0-17-generic/modules.softdep 4 5.4.0-17-generic/modules.devname 84 5.4.0-17-generic/modules.dep 12 5.4.0-17-generic/modules.builtin.bin 120 5.4.0-17-generic/modules.dep.bin 144 5.4.0-17-generic/modules.alias 28 5.4.0-17-generic/modules.builtin.alias.bin 11285.4.0-17-generic 264 5.4.0-18-generic/modules.symbols 312 5.4.0-18-generic/modules.symbols.bin 152 5.4.0-18-generic/modules.alias.bin 4 5.4.0-18-generic/modules.softdep 4 5.4.0-18-generic/modules.devname 84 5.4.0-18-generic/modules.dep 12 5.4.0-18-generic/modules.builtin.bin 120 5.4.0-18-generic/modules.dep.bin 144 5.4.0-18-generic/modules.alias 28 5.4.0-18-generic/modules.builtin.alias.bin 11285.4.0-18-generic Seems like we don't clean up enough of modules.* things on purge? ** Affects: linux (Ubuntu) Importance: Undecided Status: Invalid -- 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/1873838 Title: Purging Kernels leaves stuff behind Status in linux package in Ubuntu: Invalid Bug description: I've purged kernels Some directories were not removed because they were non-empty $ du -a ls 5.4.0-1* du: cannot access 'ls': No such file or directory 216 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.order 8 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.builtin 125.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem/modules.builtin.bin 240 5.4.0-1002-oem/usr/lib/modules/5.4.0-1002-oem 244 5.4.0-1002-oem/usr/lib/modules 248 5.4.0-1002-oem/usr/lib 252 5.4.0-1002-oem/usr 0 5.4.0-1002-oem/lib 256 5.4.0-1002-oem 0 5.4.0-14-generic/build 4 5.4.0-14-generic 264 5.4.0-16-generic/modules.symbols 312 5.4.0-16-generic/modules.symbols.bin 152 5.4.0-16-generic/modules.alias.bin 4 5.4.0-16-generic/modules.softdep 4 5.4.0-16-generic/modules.devname 845.4.0-16-generic/modules.dep 125.4.0-16-generic/modules.builtin.bin 120 5.4.0-16-generic/modules.dep.bin 144 5.4.0-16-generic/modules.alias 285.4.0-16-generic/modules.builtin.alias.bin 1128 5.4.0-16-generic 264 5.4.0-17-generic/modules.symbols 312 5.4.0-17-generic/modules.symbols.bin 152 5.4.0-17-generic/modules.alias.bin 4 5.4.0-17-generic/modules.softdep 4 5.4.0-17-generic/modules.devname 845.4.0-17-generic/modules.dep 125.4.0-17-generic/modules.builtin.bin 120 5.4.0-17-generic/modules.dep.bin 144 5.4.0-17-generic/modules.alias 285.4.0-17-generic/modules.builtin.alias.bin 1128 5.4.0-17-generic 264 5.4.0-18-generic/modules.symbols 312 5.4.0-18-generic/modules.symbols.bin 152 5.4.0-18-generic/modules.alias.bin 4 5.4.0-18-generic/modules.softdep 4 5.4.0-18-generic/modules.devname 845.4.0-18-generic/modules.dep 125.4.0-18-generic/modules.builtin.bin 120 5.4.0-18-generic/modules.dep.bin 144 5.4.0-18-generic/modules.alias 285.4.0-18-generic/modules.builtin.alias.bin 1128 5.4.0-18-generic Seems like we don't clean up enough of modules.* things on purge? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873838/+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 1873867] [NEW] ubuntu-drivers changes kernel flavour when installing nvidia
Public bug reported: $ dpkg-query -W linux-image-* linux-image-5.4.0-25-generic5.4.0-25.29 linux-image-generic-hwe-20.04 5.4.0.25.31 $ ubuntu-drivers list nvidia-driver-390 nvidia-driver-435 nvidia-driver-440 $ sudo ubuntu-drivers install Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libnvidia-cfg1-440 libnvidia-common-440 libnvidia-compute-440 libnvidia-decode-440 libnvidia-encode-440 libnvidia-extra-440 libnvidia-fbc1-440 libnvidia-gl-440 libnvidia-ifr1-440 linux-image-5.4.0-25-lowlatency linux-modules-5.4.0-25-lowlatency linux-modules-nvidia-440-5.4.0-25-lowlatency linux-modules-nvidia-440-lowlatency-hwe-20.04 nvidia-compute-utils-440 nvidia-kernel-common-440 nvidia-kernel-source-440 nvidia-prime nvidia-settings nvidia-utils-440 screen-resolution-extra xserver-xorg-video-nvidia-440 Suggested packages: fdutils linux-doc | linux-source-5.4.0 linux-tools linux-headers-5.4.0-25-lowlatency Recommended packages: libnvidia-compute-440:i386 libnvidia-decode-440:i386 libnvidia-encode-440:i386 libnvidia-ifr1-440:i386 libnvidia-fbc1-440:i386 libnvidia-gl-440:i386 The following NEW packages will be installed: libnvidia-cfg1-440 libnvidia-common-440 libnvidia-compute-440 libnvidia-decode-440 libnvidia-encode-440 libnvidia-extra-440 libnvidia-fbc1-440 libnvidia-gl-440 libnvidia-ifr1-440 linux-image-5.4.0-25-lowlatency linux-modules-5.4.0-25-lowlatency linux-modules-nvidia-440-5.4.0-25-lowlatency linux-modules-nvidia-440-lowlatency-hwe-20.04 nvidia-compute-utils-440 nvidia-driver-440 nvidia-kernel-common-440 nvidia-kernel-source-440 nvidia-prime nvidia-settings nvidia-utils-440 screen-resolution-extra xserver-xorg-video-nvidia-440 0 upgraded, 22 newly installed, 0 to remove and 0 not upgraded. I was expecting for it to pick linux-modules-nvidia-440-generic- hwe-20.04 not linux-modules-nvidia-440-lowlatency-hwe-20.04 As if it sorted things and picked last one? ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: focal -- 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/1873867 Title: ubuntu-drivers changes kernel flavour when installing nvidia Status in linux package in Ubuntu: Incomplete Bug description: $ dpkg-query -W linux-image-* linux-image-5.4.0-25-generic 5.4.0-25.29 linux-image-generic-hwe-20.04 5.4.0.25.31 $ ubuntu-drivers list nvidia-driver-390 nvidia-driver-435 nvidia-driver-440 $ sudo ubuntu-drivers install Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libnvidia-cfg1-440 libnvidia-common-440 libnvidia-compute-440 libnvidia-decode-440 libnvidia-encode-440 libnvidia-extra-440 libnvidia-fbc1-440 libnvidia-gl-440 libnvidia-ifr1-440 linux-image-5.4.0-25-lowlatency linux-modules-5.4.0-25-lowlatency linux-modules-nvidia-440-5.4.0-25-lowlatency linux-modules-nvidia-440-lowlatency-hwe-20.04 nvidia-compute-utils-440 nvidia-kernel-common-440 nvidia-kernel-source-440 nvidia-prime nvidia-settings nvidia-utils-440 screen-resolution-extra xserver-xorg-video-nvidia-440 Suggested packages: fdutils linux-doc | linux-source-5.4.0 linux-tools linux-headers-5.4.0-25-lowlatency Recommended packages: libnvidia-compute-440:i386 libnvidia-decode-440:i386 libnvidia-encode-440:i386 libnvidia-ifr1-440:i386 libnvidia-fbc1-440:i386 libnvidia-gl-440:i386 The following NEW packages will be installed: libnvidia-cfg1-440 libnvidia-common-440 libnvidia-compute-440 libnvidia-decode-440 libnvidia-encode-440 libnvidia-extra-440 libnvidia-fbc1-440 libnvidia-gl-440 libnvidia-ifr1-440 linux-image-5.4.0-25-lowlatency linux-modules-5.4.0-25-lowlatency linux-modules-nvidia-440-5.4.0-25-lowlatency linux-modules-nvidia-440-lowlatency-hwe-20.04 nvidia-compute-utils-440 nvidia-driver-440 nvidia-kernel-common-440 nvidia-kernel-source-440 nvidia-prime nvidia-settings nvidia-utils-440 screen-resolution-extra xserver-xorg-video-nvidia-440 0 upgraded, 22 newly installed, 0 to remove and 0 not upgraded. I was expecting for it to pick linux-modules-nvidia-440-generic- hwe-20.04 not linux-modules-nvidia-440-lowlatency-hwe-20.04 As if it sorted things and picked last one? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873867/+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 1876875] Re: Improve download-signed script to support current & grub2
** Patch added: "0001-UBUNTU-download-signed-improve-to-support-grub2-down.patch" https://bugs.launchpad.net/ubuntu/+source/s390-tools-signed/+bug/1876875/+attachment/5366680/+files/0001-UBUNTU-download-signed-improve-to-support-grub2-down.patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1876875 Title: Improve download-signed script to support current & grub2 Status in grub2-signed package in Ubuntu: New Status in linux-signed package in Ubuntu: New Status in s390-tools-signed package in Ubuntu: New Bug description: [Impact] * Improve and generalise download-signed script to allow using it with any signed binaries we care about * Add support to download simply the most current version * Add support to download /uefi/ signed binaries * Clean up arg parsing, add help, drop unused statements & imports. [Test Case] * Test downloading signed kernel works with public & private archives * Test that rebuilt signed .debs are the same [Regression Potential] * This is a built time script, as long the binaries are downloaded & packaged up the same, there is no end-user facing impact. [Other Info] * With these changes, download-signed script can be used by s390-tools-signed & grub2-signed, as well as all the kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1876875/+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 1876875] [NEW] Improve download-signed script to support current & grub2
Public bug reported: [Impact] * Improve and generalise download-signed script to allow using it with any signed binaries we care about * Add support to download simply the most current version * Add support to download /uefi/ signed binaries * Clean up arg parsing, add help, drop unused statements & imports. [Test Case] * Test downloading signed kernel works with public & private archives * Test that rebuilt signed .debs are the same [Regression Potential] * This is a built time script, as long the binaries are downloaded & packaged up the same, there is no end-user facing impact. [Other Info] * With these changes, download-signed script can be used by s390-tools-signed & grub2-signed, as well as all the kernels. ** Affects: grub2-signed (Ubuntu) Importance: Undecided Status: New ** Affects: linux-signed (Ubuntu) Importance: Undecided Status: New ** Affects: s390-tools-signed (Ubuntu) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu) Importance: Undecided Status: New ** Also affects: s390-tools-signed (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1876875 Title: Improve download-signed script to support current & grub2 Status in grub2-signed package in Ubuntu: New Status in linux-signed package in Ubuntu: New Status in s390-tools-signed package in Ubuntu: New Bug description: [Impact] * Improve and generalise download-signed script to allow using it with any signed binaries we care about * Add support to download simply the most current version * Add support to download /uefi/ signed binaries * Clean up arg parsing, add help, drop unused statements & imports. [Test Case] * Test downloading signed kernel works with public & private archives * Test that rebuilt signed .debs are the same [Regression Potential] * This is a built time script, as long the binaries are downloaded & packaged up the same, there is no end-user facing impact. [Other Info] * With these changes, download-signed script can be used by s390-tools-signed & grub2-signed, as well as all the kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1876875/+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 1876875] Re: Improve download-signed script to support current & grub2
https://lists.ubuntu.com/archives/kernel-team/2020-May/109572.html -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-signed in Ubuntu. https://bugs.launchpad.net/bugs/1876875 Title: Improve download-signed script to support current & grub2 Status in grub2-signed package in Ubuntu: New Status in linux-signed package in Ubuntu: New Status in s390-tools-signed package in Ubuntu: New Bug description: [Impact] * Improve and generalise download-signed script to allow using it with any signed binaries we care about * Add support to download simply the most current version * Add support to download /uefi/ signed binaries * Clean up arg parsing, add help, drop unused statements & imports. [Test Case] * Test downloading signed kernel works with public & private archives * Test that rebuilt signed .debs are the same [Regression Potential] * This is a built time script, as long the binaries are downloaded & packaged up the same, there is no end-user facing impact. [Other Info] * With these changes, download-signed script can be used by s390-tools-signed & grub2-signed, as well as all the kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1876875/+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 1877089] Re: zfcpdump kernel can not be IPLed when secure boot is requested
We can either revert the path change in s390-tools or rebuild the zfcpdump kernel flavour with the new name. ** Also affects: zfcpdump-kernel (Ubuntu) Importance: Undecided Status: New ** Also affects: s390-tools (Ubuntu) Importance: Undecided Status: New ** No longer affects: linux (Ubuntu) -- 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/1877089 Title: zfcpdump kernel can not be IPLed when secure boot is requested Status in Ubuntu on IBM z Systems: New Status in s390-tools package in Ubuntu: New Status in zfcpdump-kernel package in Ubuntu: New Bug description: I installed Ubuntu 20.04 on IBM z15 with secure=1 in zipl conf. System can be secure booted, /sys/firmware/ipl/secure shows "1". I prepared zfcp dump disk as described in LTC bug 185713. Stopped the system and performed a SCSI dump with "Enable Secure Boot for Linux" enabled. Operating System Messages on HMC: Preparing system. Starting system. System version 8. Watchdog enabled. Running 'ZBootLoader' version '1.0.0' level 'D41C.D41C_0014'. ZBootLoader 2.1.0. MLOLOA6269064E Secure IPL: There are no signed components available on device HB A=0.0.1800, WWPN=500507630309D327, LUN=40464009. IPL failed. Without "Enable Secure Boot for Linux" the dump kernel was IPLed and a dump created. Then I tried to rewrite the zfcp dump kernel with explicite setting of --secure=1: root@t35lp25:~# zipl --secure=1 -d /dev/disk/by-id/scsi-36005076303ffd3274609-part1 Building bootmap directly on partition '/dev/disk/by-id/scsi-36005076303ffd3274609-part1' Adding dump section initial ramdisk...: /lib/s390-tools/zfcpdump/zfcpdump-initrd kernel image..: /lib/s390-tools/zfcpdump/zfcpdump-image kernel parmline...: 'root=/dev/ram0 dump_mem=1 possible_cpus=1 cgroup_disable=memory ' component address: heap area...: 0x2000-0x5fff stack area..: 0xf000-0x internal loader.: 0xa000-0xdfff parameters..: 0x9000-0x91ff kernel image: 0x0001-0x001b9fff parmline: 0x001ba000-0x001ba1ff initial ramdisk.: 0x001c-0x0020edff Preparing boot device: sde. Done. ...and tried to SCSI dump this device again. But the same failure occured. Again, without "Enable Secure Boot for Linux" the dump kernel was IPLed and a dump created. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877089/+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 1877088] Re: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf
** Package changed: linux (Ubuntu) => linux-base (Ubuntu) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-base in Ubuntu. https://bugs.launchpad.net/bugs/1877088 Title: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf Status in Ubuntu on IBM z Systems: New Status in linux-base package in Ubuntu: New Bug description: When testing development kernels I usually rely on the installkernel script either through the "make install" target of the Kernel source or manually. This used to work great on Ubuntu on Z. On Ubuntu 20.04 (freshly installed up to date) this fails however because /boot/initrd.img is not updated (/boot/vmlinuz is) and thus zipl installs the wrong kernel/initrd combination rendering the system unbootable. (with the correct modules already copied to /usr/lib/modules/5.7.0-rc4-06500-gb67ea026badd/) # sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd update-initramfs: Generating /boot/initrd.img-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. run-parts: executing /etc/kernel/postinst.d/zz-zipl 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. # ls -l /boot total 178364 -rw--- 1 root root135168 May 6 11:52 bootmap -rw-r--r-- 1 root root 90471 Apr 29 15:34 config-5.4.0-29-generic lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img -> initrd.img-5.4.0-29-generic <== should point to new version -rw-r--r-- 1 root root 19663996 May 6 11:42 initrd.img-5.4.0-29-generic -rw-r--r-- 1 root root 125339494 May 6 11:52 initrd.img-5.7.0-rc4-06500-gb67ea026badd lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img.old -> initrd.img-5.4.0-29-generic -rw--- 1 root root 3087920 Apr 29 15:34 System.map-5.4.0-29-generic -rw-r--r-- 1 root root 4031691 May 6 11:52 System.map-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 4031691 May 6 11:49 System.map-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root37 May 6 11:52 vmlinuz -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw--- 1 root root 8086072 Apr 29 15:54 vmlinuz-5.4.0-29-generic -rw-r--r-- 1 root root 9080832 May 6 11:52 vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 9080832 May 6 11:49 vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root41 May 6 11:52 vmlinuz.old -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877088/+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 1877388] Re: If DVD drive is present system very often fails to start-up
what's in the dvd rom? is it empty or does it have some CD that has a package pool which apt-cdrom tries to mount (and has mounted)? -- 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/1877388 Title: If DVD drive is present system very often fails to start-up Status in linux package in Ubuntu: Confirmed Bug description: Whenever I power down, upon next boot the system just hangs with Ubuntu at the bottom of the screen and the circle above going around and around forever. It happens nearly every ime I power down, but not every single time. Rebooting rather that powering down works quite often. At first when thing hung I would just hard power off by holding down the power key. Then I'd use the live usb I installed with to run Disks app. More often than not the vfat W95 FAT32 partition at sda1 was damaged. The first repair would fail. The second repair would succeed. And then I'd be able to boot into my system again. After chatting about it a little with EriC^^ in #ubuntu on IRC I learned how to do Alt+Fn+PrtSc S, U, B or S, U, O. Sometimes just doing either of those on the hang screen would result in it booting up fine next time. Sometimes not. After installing 20.04 (a fresh install on a brand new Samsung 860 EVO 1TB sdd hard drive) I copied back all the files in my home direct that I'd backed from 18.04, including hidden files. This confused Firefox so I had to delete related folders and then unintall and reinstall to stop Firefox being confused. This might have nothing whatsoever to do with this issue, just mentioning it just in case something else is similarly confused. EriC^^ suggested I try adding another user and seeing if the issue went away. On the first test (and some but not all subsequent tests) it did seem that TestUser could power down and reboot fine. But actually it didn't seem that different. I powered down, rebooted, used live usb to repair Disk over and over again for hours trying to find a pattern as to when it happened and when it didn't, but failed to find any fixed pattern. Eventually at one point it was taking a while to power down (or reboot, I forget) and so I hit Esc and spotted that it had failed to unmount /cdrom ... ... so then I thought I'd try completely removing my DVD/CDRW drive and that made the issue go away. Before filing this I put the DVD drive back in (but haven't since rebooted), so not sure if apport has picked up it's details or not? Perhaps I'll need to re-file the bug after booting with it present? ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: plymouth 0.9.4git20200323-0ubuntu6 ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30 Uname: Linux 5.4.0-29-generic x86_64 ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Thu May 7 15:09:23 2020 DefaultPlymouth: /usr/share/plymouth/themes/bgrt/bgrt.plymouth InstallationDate: Installed on 2020-04-26 (11 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 3: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 12M MachineType: LENOVO 4384WCV ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic root=UUID=9ce94e7a-53bd-4507-ae31-93a2392b2da2 ro quiet splash vt.handoff=7 ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_GB.UTF-8 SHELL=/bin/bash ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-29-generic root=UUID=9ce94e7a-53bd-4507-ae31-93a2392b2da2 ro quiet splash vt.handoff=7 SourcePackage: plymouth TextPlymouth: /usr/share/plymouth/themes/ubuntu-text/ubuntu-text.plymouth UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/26/2010 dmi.bios.vendor: LENOVO dmi.bios.version: 6MET81WW (1.41 ) dmi.board.name: 4384WCV dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:
[Kernel-packages] [Bug 1877578] [NEW] To support older userspace running on newer kernels please backport syscall table updates in linux-libc-dev
Public bug reported: To support older userspace running on newer kernels please backport syscall table updates in linux-libc-dev. Alternatively make linux-libc-dev be shipped by a standalone source package (linux "flavour") to easily update it. Currently snapd wants to apply seccomp filters on any release and any kernel, which needs updated libseccomp, which needs updated linux-libc- dev available at build time. At the moment looking to backport syscall table numbers for the split ipc, y2038 time syscalls introduced in v5.0. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1877578 Title: To support older userspace running on newer kernels please backport syscall table updates in linux-libc-dev Status in linux package in Ubuntu: New Bug description: To support older userspace running on newer kernels please backport syscall table updates in linux-libc-dev. Alternatively make linux-libc-dev be shipped by a standalone source package (linux "flavour") to easily update it. Currently snapd wants to apply seccomp filters on any release and any kernel, which needs updated libseccomp, which needs updated linux- libc-dev available at build time. At the moment looking to backport syscall table numbers for the split ipc, y2038 time syscalls introduced in v5.0. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1877578/+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 1878432] Re: rpi3a+ does not boot with core20
Earlier ## Warning: Input data exceeds 1048576 bytes - truncated sounds already scary. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi2 in Ubuntu. https://bugs.launchpad.net/bugs/1878432 Title: rpi3a+ does not boot with core20 Status in pi2-kernel-snap: New Status in snapd: New Status in linux-raspi2 package in Ubuntu: New Bug description: MMC: mmc@7e202000: 0, mmcnr@7e30: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment RPI3a+ on core 20 from http://cdimage.ubuntu.com/ubuntu-core/20/beta/20200513.2/ (also tested the previous - 20200512.3) are not booting. This is for both arm64 and armhf. This is the serial log for as far as it gets: In:serial Out: serial Err: serial Net: No ethernet found. starting USB... Bus usb@7e98: scanning bus usb@7e98 for devices... 5 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found ## Warning: Input data exceeds 1048576 bytes - truncated ## Info: input data size = 1048578 = 0x12 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 4638 bytes read in 2 ms (2.2 MiB/s) ## Executing script at 0240 4096 bytes read in 3 ms (1.3 MiB/s) 8378005 bytes read in 363 ms (22 MiB/s) Total of 1 halfword(s) were the same Decompressing kernel... Uncompressed size: 25905664 = 0x18B4A00 33637043 bytes read in 1448 ms (22.2 MiB/s) Booting Ubuntu (with booti) from mmc 0:... ## Flattened Device Tree blob at 0260 Booting using the fdt blob at 0x260 Using Device Tree in place at 0260, end 0260a065 Starting kernel ... To manage notifications about this bug go to: https://bugs.launchpad.net/pi2-kernel-snap/+bug/1878432/+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 1878432] Re: rpi3a+ does not boot with core20
@ plars How come you manage to use Bionic classic, Focal classic, UC18 on that Pi 3A+ without adjusting config.txt and believe that this is a UC20 regression? Given that my understanding is that 3A+ needs that manual adjustment on all our other targets. ** Changed in: linux-raspi (Ubuntu) Status: New => Invalid ** Changed in: snapd Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi in Ubuntu. https://bugs.launchpad.net/bugs/1878432 Title: rpi3a+ does not boot with core20 Status in pi2-kernel-snap: New Status in snapd: Incomplete Status in linux-raspi package in Ubuntu: Invalid Status in linux-raspi source package in Focal: Invalid Bug description: MMC: mmc@7e202000: 0, mmcnr@7e30: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment RPI3a+ on core 20 from http://cdimage.ubuntu.com/ubuntu-core/20/beta/20200513.2/ (also tested the previous - 20200512.3) are not booting. This is for both arm64 and armhf. This is the serial log for as far as it gets: In:serial Out: serial Err: serial Net: No ethernet found. starting USB... Bus usb@7e98: scanning bus usb@7e98 for devices... 5 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found ## Warning: Input data exceeds 1048576 bytes - truncated ## Info: input data size = 1048578 = 0x12 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 4638 bytes read in 2 ms (2.2 MiB/s) ## Executing script at 0240 4096 bytes read in 3 ms (1.3 MiB/s) 8378005 bytes read in 363 ms (22 MiB/s) Total of 1 halfword(s) were the same Decompressing kernel... Uncompressed size: 25905664 = 0x18B4A00 33637043 bytes read in 1448 ms (22.2 MiB/s) Booting Ubuntu (with booti) from mmc 0:... ## Flattened Device Tree blob at 0260 Booting using the fdt blob at 0x260 Using Device Tree in place at 0260, end 0260a065 Starting kernel ... To manage notifications about this bug go to: https://bugs.launchpad.net/pi2-kernel-snap/+bug/1878432/+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 1878976] [NEW] Rebuild linux-raspi kernel snaps against new initrd and gate it with QA to unbreak PiFi
Public bug reported:
Rebuild linux-raspi kernel snaps against new initrd and gate it with QA
[Next Tasks]
1) Please change
https://launchpad.net/~canonical-kernel-snaps/+snap/pi-kernel--uc20 publication
channels:
from
20/beta 20/edge
to
20/edge
I.e. remove the beta risk level via the API NB!!!
$ lp-shell
snap = lp.load('~canonical-kernel-snaps/+snap/pi-kernel--uc20')
snap.store_channels = ['20/edge']
sanp.lp_save()
2) Trigger rebuild of
https://launchpad.net/~canonical-kernel-snaps/+snap/pi-kernel--uc20 such that
it is rebuild against ubuntu-core-initramfs 36
3) Notify when above is publised in 20/edge channel only
[BLOCKED]
4) [release team] => trigger respin of dangerous & edge channels of core
for UC20 (DIST=focal)
5) [ijonson|cert|cwayne] test dangerous pi image in the lab; or edge pi
image locally
6) [release team] If pifi works, kernel team is notified to promote pi-
kernel snap from 20/edge to 20/beta
7) [kernel team] promotes pi-kernel from 20/edge to 20/beta
8) [release team] respins 20/beta image
** Affects: linux-raspi (Ubuntu)
Importance: Undecided
Status: New
** Tags: core20 uc20
** Summary changed:
- Rebuild linux-raspi kernel snaps against new initrd and gate it with QA
+ Rebuild linux-raspi kernel snaps against new initrd and gate it with QA to
unbreak PiFi
** Tags added: core20
** Tags added: uc20
** Description changed:
Rebuild linux-raspi kernel snaps against new initrd and gate it with QA
[Next Tasks]
1) Please change
https://launchpad.net/~canonical-kernel-snaps/+snap/pi-kernel--uc20 publication
channels:
from
20/beta 20/edge
- to
+ to
20/edge
I.e. remove the beta risk level via the API NB!!!
- 2) Trigger rebuild of https://launchpad.net/~canonical-kernel-
- snaps/+snap/pi-kernel--uc20 such that it is rebuild against ubuntu-core-
- initramfs 36
+ $ lp-shell
+ snap = lp.load('~canonical-kernel-snaps/+snap/pi-kernel--uc20')
+ snap.store_channels = ['20/edge']
+ sanp.lp_save()
+
+
+ 2) Trigger rebuild of
https://launchpad.net/~canonical-kernel-snaps/+snap/pi-kernel--uc20 such that
it is rebuild against ubuntu-core-initramfs 36
3) Notify when above is publised in 20/edge channel only
-
[BLOCKED]
4) [release team] => trigger respin of dangerous & edge channels of core
for UC20 (DIST=focal)
5) [ijonson|cert|cwayne] test dangerous pi image in the lab; or edge pi
image locally
6) [release team] If pifi works, kernel team is notified to promote pi-
kernel snap from 20/edge to 20/beta
7) [kernel team] promotes pi-kernel from 20/edge to 20/beta
8) [release team] respins 20/beta image
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-raspi in Ubuntu.
https://bugs.launchpad.net/bugs/1878976
Title:
Rebuild linux-raspi kernel snaps against new initrd and gate it with
QA to unbreak PiFi
Status in linux-raspi package in Ubuntu:
New
Bug description:
Rebuild linux-raspi kernel snaps against new initrd and gate it with
QA
[Next Tasks]
1) Please change
https://launchpad.net/~canonical-kernel-snaps/+snap/pi-kernel--uc20 publication
channels:
from
20/beta 20/edge
to
20/edge
I.e. remove the beta risk level via the API NB!!!
$ lp-shell
snap = lp.load('~canonical-kernel-snaps/+snap/pi-kernel--uc20')
snap.store_channels = ['20/edge']
sanp.lp_save()
2) Trigger rebuild of
https://launchpad.net/~canonical-kernel-snaps/+snap/pi-kernel--uc20 such that
it is rebuild against ubuntu-core-initramfs 36
3) Notify when above is publised in 20/edge channel only
[BLOCKED]
4) [release team] => trigger respin of dangerous & edge channels of
core for UC20 (DIST=focal)
5) [ijonson|cert|cwayne] test dangerous pi image in the lab; or edge
pi image locally
6) [release team] If pifi works, kernel team is notified to promote
pi-kernel snap from 20/edge to 20/beta
7) [kernel team] promotes pi-kernel from 20/edge to 20/beta
8) [release team] respins 20/beta image
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1878976/+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 1879290] Re: pc: no message on the screen for ~30s on fast HW
** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- 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/1879290 Title: pc: no message on the screen for ~30s on fast HW Status in linux package in Ubuntu: Incomplete Status in snapd package in Ubuntu: New Bug description: The boot on real HW (ARock B450, Ryzen, NVME 240Gb) takes a long time without any visible feedback. Video: https://photos.app.goo.gl/RmaLviXNorjeh5BP7 With grub debug: https://photos.app.goo.gl/PJuXdxp8uedr7fWp9 (google photos has degraded quality quite a bit, may upload the originals if too bad) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879290/+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 1877955] Re: Fix for secure boot rules in IMA arch policy on powerpc
Hi,
Each signed object is published on in the repository under
/$suite/main/signed/$src-$arch. I.e. the linux in focal proposed signed
artefacts can be found at:
http://ports.ubuntu.com/dists/focal-proposed/main/signed/linux-ppc64el/
I.e. http://ports.ubuntu.com/dists/focal-proposed/main/signed/linux-
ppc64el/5.4.0-38.42/signed.tar.gz
inside that tarball, there should be $version/control/opal.x509 public
certificate that is used for signing.
--
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/1877955
Title:
Fix for secure boot rules in IMA arch policy on powerpc
Status in The Ubuntu-power-systems project:
Fix Committed
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Focal:
Fix Committed
Status in linux source package in Groovy:
In Progress
Bug description:
SRU Justification:
==
[Impact]
* Currently the kernel module appended signature is verified twice
(finit_module) - once by the module_sig_check() and again by IMA.
* To prevent this the powerpc secure boot rules define an IMA
architecture specific policy rule only if CONFIG_MODULE_SIG_FORCE is
not enabled.
* But this doesn't take the ability into account of enabling
"sig_enforce" at the boot command line (module.sig_enforce=1).
* Including the IMA module appraise rule results in failing the
finit_module syscall, unless the module signing public key is loaded
onto the IMA keyring.
* This patch fixes secure boot policy rules to be based on
CONFIG_MODULE_SIG instead.
[Fix]
* fa4f3f56ccd28ac031ab275e673ed4098855fed4 fa4f3f56ccd2 "powerpc/ima:
Fix secure boot rules in ima arch policy"
[Test Case]
* Perform a secure boot on a powerpc system with
'module.sig_enforce=1' set at the boot command.
* If the IMA module appraise rule is included, the finit_module
syscall will fail (unless the module signing public key got loaded
onto the IMA keyring) without having the patch in place.
* The verification needs to be done by the IBM Power team.
[Regression Potential]
* There is (always) a certain regression risk with having code
changes, especially in the secure boot area.
* But this patch is limited to the powerpc platform and will not
affect any other architecture.
* It got discussed at
https://lore.kernel.org/r/1588342612-14532-1-git-send-email-na...@linux.ibm.com
before it became finally upstream accepted with kernel 5.7-rc7.
* The secure boot code itself wasn't really touched, rather than it's basis
for execution.
The IMA policy rule for module appraisal is now added only if
'CONFIG_MODULE_SIG' is not enabled (instead of CONFIG_MODULE_SIG_FORCE).
Hence the change is very limited and straightforward.
[Other]
* Since the patch got upstream with 5.7-rc7, it is already in groovy, hence
this SRU is for focal only.
__
== Comment: #0 - Michael Ranweiler - 2020-04-22
14:44:31 ==
+++ This bug was initially created as a clone of Bug #184073 +++
This bug is a follow on to LP 1866909 to address a missing piece -
only half the following patch was included in 5.4.0-24.28.
The upstream patch has an additional fix but it?s not critical for GA.
It can get included as part of bug fixes. It also affects only power.
The patch("powerpc/ima: fix secure boot rules in ima arch policy") is
posted to linux-integrity and linuxppc-dev mailing list
(https://lore.kernel.org/linux-integrity/1586549618-6106-1-git-send-
email-na...@linux.ibm.com/T/#u)
If there are any issues identified during further testing, they will
get opened as separate issue to be addressed later.
Thanks & Regards,
- Nayna
== Comment: #4 - Michael Ranweiler - 2020-05-11
02:23:35 ==
Updated posting:
https://lore.kernel.org/linux-integrity/1588342612-14532-1-git-send-
email-na...@linux.ibm.com/T/#u
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1877955/+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 1310717] Re: process segfaults, hung task timeouts
What is gmain in the above log? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-ti-omap4 in Ubuntu. https://bugs.launchpad.net/bugs/1310717 Title: process segfaults, hung task timeouts Status in linux-ti-omap4 package in Ubuntu: New Bug description: My pandaboard ES runs irssi in a tmux session for me; irssi has died of segfaults twice recently, and dmesg had these warnings: [395523.456237] PLL GO bit not set [395523.456604] omapdss HDMI error: failed to power on device [395523.458251] [drm] Cannot find any crtc or sizes - going 1024x768 [511971.446472] INFO: task gmain:28222 blocked for more than 120 seconds. [511971.446899] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [511971.447387] gmain D c0592de8 0 28222 1414 0x0200 [511971.447479] [] (__schedule+0x65c/0x7ec) from [] (schedule+0x94/0x98) [511971.447570] [] (schedule+0x94/0x98) from [] (exit_mm+0xc0/0x138) [511971.447601] [] (exit_mm+0xc0/0x138) from [] (do_exit+0x220/0x7e8) [511971.447662] [] (do_exit+0x220/0x7e8) from [] (do_group_exit+0x94/0xd0) [511971.447723] [] (do_group_exit+0x94/0xd0) from [] (get_signal_to_deliver+0x4f0/0x568) [511971.447784] [] (get_signal_to_deliver+0x4f0/0x568) from [] (do_signal+0x94/0x4ec) [511971.447814] [] (do_signal+0x94/0x4ec) from [] (do_notify_resume+0x28/0x64) [511971.447875] [] (do_notify_resume+0x28/0x64) from [] (work_pending+0x28/0x2c) [512091.451538] INFO: task gmain:28222 blocked for more than 120 seconds. [512091.451965] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [512091.452453] gmain D c0592de8 0 28222 1414 0x0200 [512091.452514] [] (__schedule+0x65c/0x7ec) from [] (schedule+0x94/0x98) [512091.452575] [] (schedule+0x94/0x98) from [] (exit_mm+0xc0/0x138) [512091.452606] [] (exit_mm+0xc0/0x138) from [] (do_exit+0x220/0x7e8) [512091.452667] [] (do_exit+0x220/0x7e8) from [] (do_group_exit+0x94/0xd0) [512091.452728] [] (do_group_exit+0x94/0xd0) from [] (get_signal_to_deliver+0x4f0/0x568) [512091.452789] [] (get_signal_to_deliver+0x4f0/0x568) from [] (do_signal+0x94/0x4ec) [512091.452819] [] (do_signal+0x94/0x4ec) from [] (do_notify_resume+0x28/0x64) [512091.452880] [] (do_notify_resume+0x28/0x64) from [] (work_pending+0x28/0x2c) [512211.444030] INFO: task gmain:28222 blocked for more than 120 seconds. [512211.444183] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.$ [512211.444366] gmain D c0592de8 0 28222 1414 0x0200 [512211.27] [] (__schedule+0x65c/0x7ec) from [] (schedule+0x94/0x98) [512211.27] [] (schedule+0x94/0x98) from [] (exit_mm+0xc0/0x138) [512211.58] [] (exit_mm+0xc0/0x138) from [] (do_exit+0x220/0x7e8) [512211.58] [] (do_exit+0x220/0x7e8) from [] (do_group_exit+0x94/0xd0) [512211.88] [] (do_group_exit+0x94/0xd0) from [] (get_signal_to_deliver+0x4f0/0x568) [512211.444519] [] (get_signal_to_deliver+0x4f0/0x568) from [] (do_signal+0x94/0x4ec) [512211.444549] [] (do_signal+0x94/0x4ec) from [] (do_notify_resume+0x28/0x64) [512211.444549] [] (do_notify_resume+0x28/0x64) from [] (work_pending+0x28/0x2c) [512331.443237] INFO: task gmain:28222 blocked for more than 120 seconds. [512331.443389] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.$ [512331.443511] gmain D c0592de8 0 28222 1414 0x0200 [512331.443542] [] (__schedule+0x65c/0x7ec) from [] (schedule+0x94/0x98)$ [512331.443572] [] (schedule+0x94/0x98) from [] (exit_mm+0xc0/0x138) [512331.443572] [] (exit_mm+0xc0/0x138) from [] (do_exit+0x220/0x7e8)$ [512331.443603] [] (do_exit+0x220/0x7e8) from [] (do_group_exit+0x94/0xd0) [512331.443634] [] (do_group_exit+0x94/0xd0) from [] (get_signal_to_deliver+0x4f0/0x568)$ [512331.443634] [] (get_signal_to_deliver+0x4f0/0x568) from [] (do_signal+0x94/0x4ec) [512331.443664] [] (do_signal+0x94/0x4ec) from [] (do_notify_resume+0x28/0x64)$ [512331.443664] [] (do_notify_resume+0x28/0x64) from [] (work_pending+0x28/0x2c) ProblemType: Bug DistroRelease: Ubuntu 13.10 Package: linux-image-3.5.0-240-omap4 3.5.0-240.56 ProcVersionSignature: Ubuntu 3.5.0-240.56-omap4 3.5.7.31 Uname: Linux 3.5.0-240-omap4 armv7l ApportVersion: 2.12.5-0ubuntu2.2 Architecture: armhf Date: Mon Apr 21 10:18:15 2014 MarkForUpload: True ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: linux-ti-omap4 UpgradeStatus: Upgraded to saucy on 2014-01-27 (83 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1310717/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-
[Kernel-packages] [Bug 1867465] Re: Installer disconnects wifi (after choosing download while installing, 3rd party)
@ddstreet Indeed, https://www.freedesktop.org/software/systemd/man/systemd.net- naming-scheme.html b1 seems to stand for "Broadcom bus (BCMA) core number" So it seems to me that our stock vanilla kernel has gained support for this broadcom wifi chip with proper Broadcom bus support. Yet we also have some other implementation that claims to support the same chip, and then doesn't quite work the same way. I guess wl & bcmwl-kernel-source should not be both declaring support for the same chip? Such that user is not receiving one or the other, at random, or switching between the two, just because they ask installer to enable Nvidia. ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Also affects: bcmwl (Ubuntu) Importance: Undecided Status: New -- 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/1867465 Title: Installer disconnects wifi (after choosing download while installing, 3rd party) Status in systemd: Unknown Status in Release Notes for Ubuntu: Fix Released Status in bcmwl package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Won't Fix Bug description: ISO testing 20.04 daily 20200314. On the Live desktop I connect to wifi. When I click the install icon, and choose to install 3rd party (leaving download while installing checked), the wifi disconnects. I rebooted and tried again to make sure it wasn't something random. (It happened exactly the same.). This is an older Dell E5420 laptop with Broadcom BCM4313 wireless card. (Today's Lubuntu had a wifi-related problem too. I couldn't connect to wifi upon reboot after install. I had to reboot a 2nd time for it to work. I reported that to their Discourse forum, not reported as a bug yet.). I apologize that I don't know the package or pid to report this for. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-14.17-lowlatency 5.4.18 Uname: Linux 5.4.0-14-lowlatency x86_64 NonfreeKernelModules: wl zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu20 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperVersion: 1.441 CompositorRunning: None CurrentDesktop: XFCE Date: Sat Mar 14 20:29:15 2020 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 5.4.0-14-lowlatency, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell 2nd Generation Core Processor Family Integrated Graphics Controller [1028:049b] LiveMediaBuild: Ubuntu-Studio 20.04 LTS "Focal Fossa" - Alpha amd64 (20200314) MachineType: Dell Inc. Latitude E5420 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: file=/cdrom/preseed/ubuntustudio.seed initrd=/casper/initrd quiet splash --- SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/26/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A14 dmi.board.name: 0H5TG2 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA14:bd12/26/2013:svnDellInc.:pnLatitudeE5420:pvr01:rvnDellInc.:rn0H5TG2:rvrA01:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E5420 dmi.product.version: 01 dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.100-4 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.7-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1867465/+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 1867465] Re: Installer disconnects wifi (after choosing download while installing, 3rd party)
@MarkF (az2008) What you have experienced is abnormal. Normally there is only one driver for device, we offer the best driver we have, and once connected to the internet, the connection persists without any disconnects. And copies wifi config into the target installed system. Such that one never has to type the WiFi password a second time. I'm trying to troubleshoot what went wrong. As normally, we shouldn't cause such disruption at all. And thus there should be no need for confusing popups saying things about disconnects, waiting, redoing things. ** Tags removed: rls-ff-notfixing -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bcmwl in Ubuntu. https://bugs.launchpad.net/bugs/1867465 Title: Installer disconnects wifi (after choosing download while installing, 3rd party) Status in systemd: Unknown Status in Release Notes for Ubuntu: Fix Released Status in bcmwl package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Won't Fix Bug description: ISO testing 20.04 daily 20200314. On the Live desktop I connect to wifi. When I click the install icon, and choose to install 3rd party (leaving download while installing checked), the wifi disconnects. I rebooted and tried again to make sure it wasn't something random. (It happened exactly the same.). This is an older Dell E5420 laptop with Broadcom BCM4313 wireless card. (Today's Lubuntu had a wifi-related problem too. I couldn't connect to wifi upon reboot after install. I had to reboot a 2nd time for it to work. I reported that to their Discourse forum, not reported as a bug yet.). I apologize that I don't know the package or pid to report this for. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-14.17-lowlatency 5.4.18 Uname: Linux 5.4.0-14-lowlatency x86_64 NonfreeKernelModules: wl zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu20 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperVersion: 1.441 CompositorRunning: None CurrentDesktop: XFCE Date: Sat Mar 14 20:29:15 2020 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 5.4.0-14-lowlatency, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell 2nd Generation Core Processor Family Integrated Graphics Controller [1028:049b] LiveMediaBuild: Ubuntu-Studio 20.04 LTS "Focal Fossa" - Alpha amd64 (20200314) MachineType: Dell Inc. Latitude E5420 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: file=/cdrom/preseed/ubuntustudio.seed initrd=/casper/initrd quiet splash --- SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/26/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A14 dmi.board.name: 0H5TG2 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA14:bd12/26/2013:svnDellInc.:pnLatitudeE5420:pvr01:rvnDellInc.:rn0H5TG2:rvrA01:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E5420 dmi.product.version: 01 dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.100-4 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.7-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1867465/+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 1867465] Re: Installer disconnects wifi (after choosing download while installing, 3rd party)
@Alberto Milone Something odd is happening for the user of BCM4313 wifi chip. The devices appears to jump from bus1 to bus0, and thus getting a new name. Or as if, there are two different drivers offered to the user and/or operational via different buses. Such that udev identifies the same card on bus1 at first, and then later at bus0 and thus generates wlp2s0b1 name at first, and then wlp2s0 device name (not that when bus is 0, b0 is ommitted). -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bcmwl in Ubuntu. https://bugs.launchpad.net/bugs/1867465 Title: Installer disconnects wifi (after choosing download while installing, 3rd party) Status in systemd: Unknown Status in Release Notes for Ubuntu: Fix Released Status in bcmwl package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Status in ubiquity package in Ubuntu: Won't Fix Bug description: ISO testing 20.04 daily 20200314. On the Live desktop I connect to wifi. When I click the install icon, and choose to install 3rd party (leaving download while installing checked), the wifi disconnects. I rebooted and tried again to make sure it wasn't something random. (It happened exactly the same.). This is an older Dell E5420 laptop with Broadcom BCM4313 wireless card. (Today's Lubuntu had a wifi-related problem too. I couldn't connect to wifi upon reboot after install. I had to reboot a 2nd time for it to work. I reported that to their Discourse forum, not reported as a bug yet.). I apologize that I don't know the package or pid to report this for. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-14.17-lowlatency 5.4.18 Uname: Linux 5.4.0-14-lowlatency x86_64 NonfreeKernelModules: wl zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu20 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperVersion: 1.441 CompositorRunning: None CurrentDesktop: XFCE Date: Sat Mar 14 20:29:15 2020 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DkmsStatus: bcmwl, 6.30.223.271+bdcom, 5.4.0-14-lowlatency, x86_64: installed ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell 2nd Generation Core Processor Family Integrated Graphics Controller [1028:049b] LiveMediaBuild: Ubuntu-Studio 20.04 LTS "Focal Fossa" - Alpha amd64 (20200314) MachineType: Dell Inc. Latitude E5420 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: file=/cdrom/preseed/ubuntustudio.seed initrd=/casper/initrd quiet splash --- SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/26/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A14 dmi.board.name: 0H5TG2 dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA14:bd12/26/2013:svnDellInc.:pnLatitudeE5420:pvr01:rvnDellInc.:rn0H5TG2:rvrA01:cvnDellInc.:ct9:cvr: dmi.product.name: Latitude E5420 dmi.product.version: 01 dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.100-4 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.0-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.7-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1867465/+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 1877533] Re: [20.10 FEAT] Increase the crashkernel setting if the root volume is luks2-encrypted
@fheimes No, in comment #2 I did not agree to bump the parameter. @heinz-werner_seeck My previous comment was not responded to. LUKS2 and Argon2i have no effect on steady state RAM usage, and thus should not affect crashkernel memory requirements significantly. Normally, Argon2i decryption has high memory pressure only once during unlocking of the drive, but not during the steady state operation. Please explain how the new crashkernel size has been calculated, and why is it so much larger than before? ** Changed in: makedumpfile (Ubuntu Groovy) Status: Confirmed => Incomplete ** Changed in: ubuntu-z-systems Status: Confirmed => Incomplete ** Changed in: makedumpfile (Ubuntu Focal) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1877533 Title: [20.10 FEAT] Increase the crashkernel setting if the root volume is luks2-encrypted Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Incomplete Status in linux source package in Focal: Invalid Status in makedumpfile source package in Focal: Incomplete Status in linux source package in Groovy: Invalid Status in makedumpfile source package in Groovy: Incomplete Bug description: Description: In case the volume containing the root filesystem is encrypted using LUKS2 the memory used while unlocking the volume may exceed the size allocated to the kdump kernel. This will lead to a failure while processing kdump and the dump file will not be stored. Unfortunately, this condition may not be detected by a client before a problem occurs. The request is to have the kdump package installation script check for LUKS2 encryption (more precisely for Argon2i PBKDF, which is the root cause of the high memory usage). If the condition is met, the installation procedure should increase the crashkernel parameter to a higher value (>=512M)or issue a warning, if the system memory is insufficient to reserve enough crashkernel memory. Business Case: Pervasive Encryption and Secure Execution require encryption of the filesystems in order to keep customer data secure at all times. With the increasing usage of these technologies, the number of kdump will rise too, typically at inconvenient times, when the kdump is triggered due to a real customer issue. With the suggested change, the number of customer complaints and effort to handle them will be reduced. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+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 1884281] Re: UC20 images do not use predictable interface names on RPi4
UC20 only uses predictable names. It is intentional to use stable names. There is nothing in the gadget about it. But rather kernel drivers, dtb, udev. eth0 name is a bug. And it means udev failed to establish a predictable name for it. I think we either need to add an additional policy file for it, to at least use mac based name and/or work with kernel & upstream to positively identify it. ** Also affects: linux-raspi2 (Ubuntu) Importance: Undecided Status: New ** Package changed: linux-raspi2 (Ubuntu) => linux-raspi (Ubuntu) ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi2 in Ubuntu. https://bugs.launchpad.net/bugs/1884281 Title: UC20 images do not use predictable interface names on RPi4 Status in snapd: Triaged Status in linux-raspi package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Image tested: http://cdimage.ubuntu.com/ubuntu-core/20/dangerous- beta/pending/ubuntu-core-20-arm64+raspi.img.xz Boot the image and check the naming of the ethernet interfaces. On most devices (amd64, rpi3 etc) systemd predicatable interface naming is applied e.g. enxb827eb7d1eee. However on specifically RPi4 devices traditional naming is used e.g. eth0, eth1. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1884281/+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 1877533] Re: [20.10 FEAT] Increase the crashkernel setting if the root volume is luks2-encrypted
encrypted volume of the system being dump, or the encrypted volume which is the target where to store the dump? (and thus more memory is needed to unlock the drive?) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1877533 Title: [20.10 FEAT] Increase the crashkernel setting if the root volume is luks2-encrypted Status in Ubuntu on IBM z Systems: Triaged Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Incomplete Status in linux source package in Focal: Invalid Status in makedumpfile source package in Focal: Incomplete Status in linux source package in Groovy: Invalid Status in makedumpfile source package in Groovy: Incomplete Bug description: Description: In case the volume containing the root filesystem is encrypted using LUKS2 the memory used while unlocking the volume may exceed the size allocated to the kdump kernel. This will lead to a failure while processing kdump and the dump file will not be stored. Unfortunately, this condition may not be detected by a client before a problem occurs. The request is to have the kdump package installation script check for LUKS2 encryption (more precisely for Argon2i PBKDF, which is the root cause of the high memory usage). If the condition is met, the installation procedure should increase the crashkernel parameter to a higher value (>=512M)or issue a warning, if the system memory is insufficient to reserve enough crashkernel memory. Business Case: Pervasive Encryption and Secure Execution require encryption of the filesystems in order to keep customer data secure at all times. With the increasing usage of these technologies, the number of kdump will rise too, typically at inconvenient times, when the kdump is triggered due to a real customer issue. With the suggested change, the number of customer complaints and effort to handle them will be reduced. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+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 1877088] Re: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf
Eoan and later d-i, new installer, curtin do not install /etc/kernel-img.conf. Upgraded systems keep having it (ie. installed with bionic or xenial, and upgraded). Can you please let me know if _removing_ /etc/kernel-img.conf breaks $ sudo make install, and if adding /etc/kernel-img.conf back fixes $ sudo make install? Cause the expectation is that `/etc/kernel-img.conf` should not be there, yet everything should still work correctly. I think somewhere something is reading "link_in_boot=yes" and was not updated with the new implicit default to always assume that on recent ubuntu. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-base in Ubuntu. https://bugs.launchpad.net/bugs/1877088 Title: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf Status in Ubuntu on IBM z Systems: Triaged Status in debianutils package in Ubuntu: New Status in linux-base package in Ubuntu: New Bug description: When testing development kernels I usually rely on the installkernel script either through the "make install" target of the Kernel source or manually. This used to work great on Ubuntu on Z. On Ubuntu 20.04 (freshly installed up to date) this fails however because /boot/initrd.img is not updated (/boot/vmlinuz is) and thus zipl installs the wrong kernel/initrd combination rendering the system unbootable. (with the correct modules already copied to /usr/lib/modules/5.7.0-rc4-06500-gb67ea026badd/) # sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd update-initramfs: Generating /boot/initrd.img-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. run-parts: executing /etc/kernel/postinst.d/zz-zipl 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. # ls -l /boot total 178364 -rw--- 1 root root135168 May 6 11:52 bootmap -rw-r--r-- 1 root root 90471 Apr 29 15:34 config-5.4.0-29-generic lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img -> initrd.img-5.4.0-29-generic <== should point to new version -rw-r--r-- 1 root root 19663996 May 6 11:42 initrd.img-5.4.0-29-generic -rw-r--r-- 1 root root 125339494 May 6 11:52 initrd.img-5.7.0-rc4-06500-gb67ea026badd lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img.old -> initrd.img-5.4.0-29-generic -rw--- 1 root root 3087920 Apr 29 15:34 System.map-5.4.0-29-generic -rw-r--r-- 1 root root 4031691 May 6 11:52 System.map-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 4031691 May 6 11:49 System.map-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root37 May 6 11:52 vmlinuz -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw--- 1 root root 8086072 Apr 29 15:54 vmlinuz-5.4.0-29-generic -rw-r--r-- 1 root root 9080832 May 6 11:52 vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 9080832 May 6 11:49 vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root41 May 6 11:52 vmlinuz.old -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877088/+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
Re: [Kernel-packages] [Bug 1877088] Comment bridged from LTC Bugzilla
On Fri, 26 Jun 2020 at 15:01, bugproxy <1877...@bugs.launchpad.net> wrote: > > --- Comment From niklas.schne...@ibm.com 2020-06-26 09:45 EDT--- > (In reply to comment #17) > > Eoan and later d-i, new installer, curtin do not install > > /etc/kernel-img.conf. > > Upgraded systems keep having it (ie. installed with bionic or xenial, and > > upgraded). > > > > Can you please let me know if _removing_ /etc/kernel-img.conf breaks $ sudo > > make install, and if adding /etc/kernel-img.conf back fixes $ sudo make > > install? > > > > Cause the expectation is that `/etc/kernel-img.conf` should not be there, > > yet everything should still work correctly. > > > > I think somewhere something is reading "link_in_boot=yes" and was not > > updated with the new implicit default to always assume that on recent > > ubuntu. > > For me the installkernel script (including in the current case "sudo > make install" from a mainline Linux tree) doesn't update the > /boot/initrd.img symlink. > > Interestingly a package upgrade for linux-generic does overwrite this > symlink. .deb package uses very different maintainer scripts / codepath, and is not the same operation as "sudo make install". I personally always build my kernels as debs, and install debs, rather than doing "sudo make install". But I am a distribution developer, and I care for .debs to work right. Kernel developers, I guess, are inverse, and care for "upstream" $ sudo make install to work. > > Not with the /etc/kernel-img.conf[0] and not without it either. > As before the /boot/vmlinuz link is always updated. > That is slightly concerning, as to how $ sudo make install, ever worked before. Or what has changed since. Normally, $ sudo make install, should lookup if /sbin/installkernel is available, and call that to "do what it has to do, on a given distribution", and that script is shipped by the debianutils package which is required and must be installed always. And it hasn't been touched in ages. I wonder which arguments are passed to /sbin/installkernel by $ sudo make install. And whether the 4th argument is passed, and if it is empty, /, or /boot. It should be either empty, or /boot. -- Regards, Dimitri. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-base in Ubuntu. https://bugs.launchpad.net/bugs/1877088 Title: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf Status in Ubuntu on IBM z Systems: Triaged Status in debianutils package in Ubuntu: New Status in linux-base package in Ubuntu: New Bug description: When testing development kernels I usually rely on the installkernel script either through the "make install" target of the Kernel source or manually. This used to work great on Ubuntu on Z. On Ubuntu 20.04 (freshly installed up to date) this fails however because /boot/initrd.img is not updated (/boot/vmlinuz is) and thus zipl installs the wrong kernel/initrd combination rendering the system unbootable. (with the correct modules already copied to /usr/lib/modules/5.7.0-rc4-06500-gb67ea026badd/) # sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd update-initramfs: Generating /boot/initrd.img-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. run-parts: executing /etc/kernel/postinst.d/zz-zipl 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. # ls -l /boot total 178364 -rw--- 1 root root135168 May 6 11:52 bootmap -rw-r--r-- 1 root root 90471 Apr 29 15:34 config-5.4.0-29-generic lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img -> initrd.img-5.4.0-29-generic <== should point to new version -rw-r--r-- 1 root root 19663996 May 6 11:42 initrd.img-5.4.0-29-generic -rw-r--r-- 1 root root 125339494 May 6 11:52 initrd.img-5.7.0-rc4-06500-gb67ea026badd lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img.old -> initrd.img-5.4.0-29-generic -rw--- 1 root root 3087920 Apr 29 15:34 System.map-5.4.0-29-generic -rw-r--r-- 1 root root 4031691 May 6 11:52 System.map-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 4031691 May 6 11:49 System.map-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root
