[Kernel-packages] [Bug 1931129] Re: v5.13 net bpf selftests fail with older clang toolchains
** Patch added: "0001-selftests-bpf-add-ifdefs-in-tests-for-required-Clang.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931129/+attachment/5502940/+files/0001-selftests-bpf-add-ifdefs-in-tests-for-required-Clang.patch -- 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/1931129 Title: v5.13 net bpf selftests fail with older clang toolchains Status in linux package in Ubuntu: New Bug description: selftests/bpf: add ifdefs in tests for required Clang versions This codifies the clang version requirements from README.rst in the code, such that only expected working test cases are compiled for the expected clang version combinations. This insures that most tests are still executed, even when one doesn't have access to the latest clang toolchain. Also see internal v5.13 test results. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931129/+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 1931129] [NEW] v5.13 net bpf selftests fail with older clang toolchains
Public bug reported: selftests/bpf: add ifdefs in tests for required Clang versions This codifies the clang version requirements from README.rst in the code, such that only expected working test cases are compiled for the expected clang version combinations. This insures that most tests are still executed, even when one doesn't have access to the latest clang toolchain. Also see internal v5.13 test results. ** 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/1931129 Title: v5.13 net bpf selftests fail with older clang toolchains Status in linux package in Ubuntu: New Bug description: selftests/bpf: add ifdefs in tests for required Clang versions This codifies the clang version requirements from README.rst in the code, such that only expected working test cases are compiled for the expected clang version combinations. This insures that most tests are still executed, even when one doesn't have access to the latest clang toolchain. Also see internal v5.13 test results. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931129/+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 1930733] Re: Kernel oops with the 460.80 and 465.27 drivers when using DP, but not with HDMI
https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-460 460.84 is available in impish-proposed, but as dkms only at the moment - not yet available as signed lrm package. It would be nice to know if 460.84 works or not. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-460 in Ubuntu. https://bugs.launchpad.net/bugs/1930733 Title: Kernel oops with the 460.80 and 465.27 drivers when using DP, but not with HDMI Status in nvidia-graphics-drivers-460 package in Ubuntu: Triaged Status in nvidia-graphics-drivers-465 package in Ubuntu: Triaged Bug description: I get a kernel oops with the 460.80 and 465.27 drivers on Hirsute Jun 03 16:26:57 willow kernel: Oops: [#1] SMP PTI Jun 03 16:26:57 willow kernel: CPU: 7 PID: 2004 Comm: Xorg Tainted: P OE 5.11.0-18-generic #19-Ubuntu Jun 03 16:26:57 willow kernel: Hardware name: System manufacturer System Product Name/PRIME H270M-PLUS, BIOS 1605 12/13/2019 Jun 03 16:26:57 willow kernel: RIP: 0010:_nv015534rm+0x1b6/0x330 [nvidia] Jun 03 16:26:57 willow kernel: Code: 8b 87 68 05 00 00 ba 01 00 00 00 be 02 00 00 00 e8 bf eb 55 c8 41 83 c5 01 41 83 fd 1f 0f 84 0b 01 00 00 48 8b 45 10 44 89 ee <48> 8b b8 70 01 00 00 48 8b 87 d8 04 00 00 e8> Jun 03 16:26:57 willow kernel: RSP: :af4201893958 EFLAGS: 00010297 Jun 03 16:26:57 willow kernel: RAX: RBX: 0400 RCX: 0003 Jun 03 16:26:57 willow kernel: RDX: 0004 RSI: 0003 RDI: Jun 03 16:26:57 willow kernel: RBP: 8e318220add0 R08: 0001 R09: 8e318220acb8 Jun 03 16:26:57 willow kernel: R10: 8e3182204008 R11: 1010 R12: 0400 Jun 03 16:26:57 willow kernel: R13: 0003 R14: 8e3186ca8010 R15: 0800 Jun 03 16:26:57 willow kernel: FS: 7f5807f38a40() GS:8e3466dc() knlGS: Jun 03 16:26:57 willow kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 03 16:26:57 willow kernel: CR2: 0170 CR3: 000140710005 CR4: 003706e0 Jun 03 16:26:57 willow kernel: DR0: DR1: DR2: Jun 03 16:26:57 willow kernel: DR3: DR6: fffe0ff0 DR7: 0400 Jun 03 16:26:57 willow kernel: Call Trace: Jun 03 16:26:57 willow kernel: ? _nv015556rm+0x7fd/0x1020 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv027155rm+0x22c/0x4f0 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv017787rm+0x303/0x5e0 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv017789rm+0xe1/0x220 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv022829rm+0xed/0x220 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv023065rm+0x30/0x60 [nvidia] Jun 03 16:26:57 willow kernel: ? _nv000704rm+0x16da/0x22b0 [nvidia] Jun 03 16:26:57 willow kernel: ? rm_init_adapter+0xc5/0xe0 [nvidia] Jun 03 16:26:57 willow kernel: ? nv_open_device+0x122/0x8e0 [nvidia] Jun 03 16:26:57 willow kernel: ? nvidia_open+0x2b7/0x560 [nvidia] Jun 03 16:26:57 willow kernel: ? nvidia_frontend_open+0x58/0xa0 [nvidia] Jun 03 16:26:57 willow kernel: ? chrdev_open+0xf7/0x220 Jun 03 16:26:57 willow kernel: ? cdev_device_add+0x90/0x90 Jun 03 16:26:57 willow kernel: ? do_dentry_open+0x156/0x370 Jun 03 16:26:57 willow kernel: ? vfs_open+0x2d/0x30 Jun 03 16:26:57 willow kernel: ? do_open+0x1c3/0x340 Jun 03 16:26:57 willow kernel: ? path_openat+0x10a/0x1d0 Jun 03 16:26:57 willow kernel: ? do_filp_open+0x8c/0x130 Jun 03 16:26:57 willow kernel: ? __check_object_size+0x1c/0x20 Jun 03 16:26:57 willow kernel: ? do_sys_openat2+0x9b/0x150 Jun 03 16:26:57 willow kernel: ? __x64_sys_openat+0x56/0x90 Jun 03 16:26:57 willow kernel: ? do_syscall_64+0x38/0x90 Jun 03 16:26:57 willow kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jun 03 16:26:57 willow kernel: Modules linked in: snd_seq_dummy snd_hrtimer vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc zfs(PO) zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) > Jun 03 16:26:57 willow kernel: sunrpc ip_tables x_tables autofs4 btrfs blake2b_generic xor raid6_pq libcrc32c hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd c> Jun 03 16:26:57 willow kernel: CR2: 0170 Jun 03 16:26:57 willow kernel: ---[ end trace 0013b6989b267f32 ]--- Jun 03 16:26:57 willow kernel: RIP: 0010:_nv015534rm+0x1b6/0x330 [nvidia] Jun 03 16:26:57 willow kernel: Code: 8b 87 68 05 00 00 ba 01 00 00 00 be 02 00 00 00 e8 bf eb 55 c8 41 83 c5 01 41 83 fd 1f 0f 84 0b 01 00 00 48 8b 45 10 44 89 ee <48> 8b b8 70 01 00 00 48 8b 87 d8 04 00 00 e8> Jun 03 16:26:57 willow kernel: RSP: :af4201893958 EFLAGS: 00010297 Jun 03 16:26:57 willow kernel: RAX: RBX: 0400 RCX: 0003 Jun 03 16:26:57
[Kernel-packages] [Bug 1926330] Re: HWE kernels should enable BTF support to enable eBPF RO.CE support
And for v5.13 kernels even newer dwarves-dfsg is needed. ** Changed in: dwarves-dfsg (Ubuntu Bionic) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Bionic) Status: Confirmed => Won't Fix ** Changed in: dwarves-dfsg (Ubuntu) Status: Confirmed => Fix Released ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Also affects: linux (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: dwarves-dfsg (Ubuntu Hirsute) 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/1926330 Title: HWE kernels should enable BTF support to enable eBPF RO.CE support Status in dwarves-dfsg package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in dwarves-dfsg source package in Bionic: Won't Fix Status in linux source package in Bionic: Won't Fix Status in dwarves-dfsg source package in Focal: Confirmed Status in linux source package in Focal: Confirmed Status in dwarves-dfsg source package in Groovy: Fix Released Status in linux source package in Groovy: Fix Released Status in dwarves-dfsg source package in Hirsute: New Status in linux source package in Hirsute: New Bug description: I had recent discussion with kernel team regarding support or not BTF in HWE kernels (Bionic and Focal). Having CONFIG_DEBUG_INFO_BTF option enabled for HWE kernels (v4.4 and v.4.8) would allow eBPF based code (powered by libbpf or not) to be RO.CE (https://github.com/rafaeldtinoco/portablebpf for more information). By allowing runtime relocations, using provided BTF, libbpf binaries might end up running, without modifications, in different kernel versions (from Bionic HWE v5.4 kernel to Hirsute v5.11). A good example would be to support tools such as: https://github.com/aquasecurity/tracee/discussions/713#discussioncomment-665641 An ebpf powered backend for a containers security solution. Considering: $ rmadisonb dwarves dwarves | 1.9-1 | precise/universe | amd64 dwarves | 1.10-2 | trusty | amd64 dwarves | 1.10-2.1 | xenial/universe | amd64 dwarves | 1.10-2.1build1 | bionic/universe | amd64 dwarves | 1.15-2 | focal/universe | amd64 dwarves | 1.17-1 | groovy/universe | amd64 dwarves | 1.20-1 | hirsute/universe | amd64 dwarves | 1.20-1 | impish/universe | amd64 And the fact that the 'pahole' binary, from dwarves package, is the one to blame, not to have CONFIG_DEBUG_INFO_BTF available, for this bug to be solved we would have to provide a backport of dwarves (at least 1.17-1) to Bionic and Focal. It could have another name (not to mess with original dwarves package and its dependencies) and it is unclear if it needs to be in [main] or [universe]. Question: Would have dwarves backported in -backports be enough for Bionic and Focal HWE kernels compilation to have CONFIG_DEBUG_INFO_BTF enabled ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dwarves-dfsg/+bug/1926330/+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 1932329] [NEW] Benchmark if we can compress kernel modules
Public bug reported: Symbol: MODULE_COMPRESS_ZSTD [=n] Type : bool = Impacts to measure and observe = == Disk space == * Inspect linux-modules-* and linux-modules-extra* deb package Installed-Size and Download-Size changes, i.e. $ apt show linux-modules-5.8.0-53-generic linux-modules- extra-5.8.0-53-generic | grep -e Package: -e Size: Package: linux-modules-5.8.0-53-generic Installed-Size: 81.5 MB Download-Size: 15.5 MB Package: linux-modules-extra-5.8.0-53-generic Installed-Size: 215 MB Download-Size: 41.5 MB In theory, there should not be a significant change in the Download- size. It is desired that there is a significant reduction in Installed- Size. Modules take up about 300MB and normally one has upto three kernel version installed, resulting in about of 1GB of disk space that one constantly pays for. == Boot Speed == In theory, boot speed may either improve or regress. It depends if disk IO is slower than decompression speed, meaning loading compressed modules is faster. Also one has to observe the changes in the initrd size. zstd(zstd) compression may result in slight growth, which shouldn't impact boot speed too much. = Outcomes = If installed size savings can be achieved without regressing bootspeed we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default. ** Affects: linux (Ubuntu) Importance: Medium Assignee: Colin Ian King (colin-king) Status: In Progress ** Tags: performance zstd ** Changed in: linux (Ubuntu) Status: New => Incomplete ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Colin Ian King (colin-king) -- 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/1932329 Title: Benchmark if we can compress kernel modules Status in linux package in Ubuntu: In Progress Bug description: Symbol: MODULE_COMPRESS_ZSTD [=n] Type : bool = Impacts to measure and observe = == Disk space == * Inspect linux-modules-* and linux-modules-extra* deb package Installed-Size and Download-Size changes, i.e. $ apt show linux-modules-5.8.0-53-generic linux-modules- extra-5.8.0-53-generic | grep -e Package: -e Size: Package: linux-modules-5.8.0-53-generic Installed-Size: 81.5 MB Download-Size: 15.5 MB Package: linux-modules-extra-5.8.0-53-generic Installed-Size: 215 MB Download-Size: 41.5 MB In theory, there should not be a significant change in the Download- size. It is desired that there is a significant reduction in Installed-Size. Modules take up about 300MB and normally one has upto three kernel version installed, resulting in about of 1GB of disk space that one constantly pays for. == Boot Speed == In theory, boot speed may either improve or regress. It depends if disk IO is slower than decompression speed, meaning loading compressed modules is faster. Also one has to observe the changes in the initrd size. zstd(zstd) compression may result in slight growth, which shouldn't impact boot speed too much. = Outcomes = If installed size savings can be achieved without regressing bootspeed we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932329/+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 1932354] Re: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable)
The following packages have unmet dependencies: systemd-tests : Depends: libsystemd0 (= 247.3-3ubuntu3.1) but 247.3-3ubuntu3 is to be installed Depends: systemd (= 247.3-3ubuntu3.1) -- 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/1932354 Title: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable) Status in linux package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: This is a scripted bug report about ADT failures while running systemd tests for linux/5.11.0-20.21 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210617_171802_98347@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/armhf/s/systemd/20210616_224930_60c1e@/log.gz storage PASS networkd-test.py FAIL non-zero exit status 1 build-login FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-and-servicesFAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. udev FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. root-unittests FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. tests-in-lxd SKIP installation fails and skip-not-installable set upstream FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-smoke FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. systemd-fsckdSKIP exit status 77 and marked as skippable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932354/+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 1932354] Re: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable)
Retrying these once. -- 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/1932354 Title: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable) Status in linux package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: This is a scripted bug report about ADT failures while running systemd tests for linux/5.11.0-20.21 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210617_171802_98347@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/armhf/s/systemd/20210616_224930_60c1e@/log.gz storage PASS networkd-test.py FAIL non-zero exit status 1 build-login FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-and-servicesFAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. udev FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. root-unittests FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. tests-in-lxd SKIP installation fails and skip-not-installable set upstream FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-smoke FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. systemd-fsckdSKIP exit status 77 and marked as skippable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932354/+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 1932354] Re: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable)
I am told it is an apt bug, due to systemd package being phased. See https://launchpad.net/bugs/1925745 -- 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/1932354 Title: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable) Status in linux package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: This is a scripted bug report about ADT failures while running systemd tests for linux/5.11.0-20.21 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210617_171802_98347@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/armhf/s/systemd/20210616_224930_60c1e@/log.gz storage PASS networkd-test.py FAIL non-zero exit status 1 build-login FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-and-servicesFAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. udev FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. root-unittests FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. tests-in-lxd SKIP installation fails and skip-not-installable set upstream FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-smoke FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. systemd-fsckdSKIP exit status 77 and marked as skippable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932354/+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 1932354] Re: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable)
I wonder if this is ADT cloud failure. -- 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/1932354 Title: systemd/247.3-3ubuntu3.1 ADT test failure with linux/5.11.0-20.21 (Test dependencies are unsatisfiable) Status in linux package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: This is a scripted bug report about ADT failures while running systemd tests for linux/5.11.0-20.21 on hirsute. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210617_171802_98347@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute/hirsute/armhf/s/systemd/20210616_224930_60c1e@/log.gz storage PASS networkd-test.py FAIL non-zero exit status 1 build-login FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-and-servicesFAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. udev FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. root-unittests FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. tests-in-lxd SKIP installation fails and skip-not-installable set upstream FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. boot-smoke FAIL badpkg blame: systemd badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. systemd-fsckdSKIP exit status 77 and marked as skippable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932354/+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 1929255] Re: update-initrd-links creates incorrect symlinks
@fmalfoy it was fixed with the 06-04 round of sru updates. Does the new linux-base from proposed not resolve the reported regressions for you? -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1932582] Re: Implement support for Intel SGX
** Description changed: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR + systemctl --system show-environment | grep SGX_AESM_ADDR + login via tty and check $ env | grep SGX_AESM_ADDR + login via ssh and check $ env | grep SGX_AESM_ADDR + [other info] SF:00308240 -- 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/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: In Progress Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: In Progress Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: In Progress Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1929255] Re: update-initrd-links creates incorrect symlinks
focal: link_in_boot = no # dpkg-query -W linux-base linux-base 4.5ubuntu3.5 # Two regular flavours # ls -latr / | grep -- '->' | grep boot | sort lrwxrwxrwx 1 root root 29 Jun 23 13:40 vmlinuz.old -> boot/vmlinuz-5.4.0-78-generic lrwxrwxrwx 1 root root 32 Jun 23 13:40 initrd.img.old -> boot/initrd.img-5.4.0-78-generic lrwxrwxrwx 1 root root 32 Jun 23 13:57 vmlinuz -> boot/vmlinuz-5.4.0-78-lowlatency lrwxrwxrwx 1 root root 35 Jun 23 13:57 initrd.img -> boot/initrd.img-5.4.0-78-lowlatency # selfbuilt installkernel 5.13.0-051300rc7-generic image/boot/vmlinuz-5.13.0-051300rc7-generic modules/boot/System.map-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.4.0-78-lowlatency I: /initrd.img.old is now a symlink to boot/initrd.img-5.4.0-78-lowlatency I: /vmlinuz is now a symlink to boot/vmlinuz-5.13.0-051300rc7-generic I: /initrd.img is now a symlink to boot/initrd.img-5.13.0-051300rc7-generic # ls -latr / | grep -- '->' | grep boot | sort lrwxrwxrwx 1 root root 32 Jun 23 14:04 vmlinuz.old -> boot/vmlinuz-5.4.0-78-lowlatency lrwxrwxrwx 1 root root 35 Jun 23 14:04 initrd.img.old -> boot/initrd.img-5.4.0-78-lowlatency lrwxrwxrwx 1 root root 37 Jun 23 14:04 vmlinuz -> boot/vmlinuz-5.13.0-051300rc7-generic lrwxrwxrwx 1 root root 40 Jun 23 14:04 initrd.img -> boot/initrd.img-5.13.0-051300rc7-generic ** Tags added: verification-done-focal -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- Mailing list:
[Kernel-packages] [Bug 1929255] Re: update-initrd-links creates incorrect symlinks
Focal: link_in_boot = yes # dpkg-query -W linux-base linux-base 4.5ubuntu3.5 # Two regular flavours # ls -latr /boot/ | grep -- '->' | sort lrwxrwxrwx 1 root root 24 Jun 23 11:18 vmlinuz.old -> vmlinuz-5.4.0-78-generic lrwxrwxrwx 1 root root 27 Jun 23 11:18 initrd.img.old -> initrd.img-5.4.0-78-generic lrwxrwxrwx 1 root root 27 Jun 23 11:20 vmlinuz -> vmlinuz-5.4.0-78-lowlatency lrwxrwxrwx 1 root root 30 Jun 23 11:20 initrd.img -> initrd.img-5.4.0-78-lowlatency # selfbuilt # installkernel 5.13.0-051300rc7-generic image/boot/vmlinuz-5.13.0-051300rc7-generic modules/boot/System.map-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic I: /boot/initrd.img.old is now a symlink to initrd.img-5.4.0-78-lowlatency I: /boot/initrd.img is now a symlink to initrd.img-5.13.0-051300rc7-generic # ls -latr /boot/ | grep -- '->' | sort lrwxrwxrwx 1 root root 27 Jun 23 11:20 vmlinuz.old -> vmlinuz-5.4.0-78-lowlatency lrwxrwxrwx 1 root root 30 Jun 23 11:23 initrd.img.old -> initrd.img-5.4.0-78-lowlatency lrwxrwxrwx 1 root root 32 Jun 23 11:22 vmlinuz -> vmlinuz-5.13.0-051300rc7-generic lrwxrwxrwx 1 root root 35 Jun 23 11:23 initrd.img -> initrd.img-5.13.0-051300rc7-generic All is good. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
bionic: link_in_boot = no # dpkg-query -W linux-base linux-base 4.5ubuntu1.6 # Two regular flavours # ls -latr / | grep -- '->' | grep boot | sort lrwxrwxrwx 1 root root 31 Jun 23 14:18 vmlinuz.old -> boot/vmlinuz-4.15.0-147-generic lrwxrwxrwx 1 root root 34 Jun 23 14:18 initrd.img.old -> boot/initrd.img-4.15.0-147-generic lrwxrwxrwx 1 root root 34 Jun 23 14:20 vmlinuz -> boot/vmlinuz-4.15.0-147-lowlatency lrwxrwxrwx 1 root root 37 Jun 23 14:20 initrd.img -> boot/initrd.img-4.15.0-147-lowlatency # selfbuilt # installkernel 5.13.0-051300rc7-generic image/boot/vmlinuz-5.13.0-051300rc7-generic modules/boot/System.map-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic I: /vmlinuz.old is now a symlink to boot/vmlinuz-4.15.0-147-lowlatency I: /initrd.img.old is now a symlink to boot/initrd.img-4.15.0-147-lowlatency I: /vmlinuz is now a symlink to boot/vmlinuz-5.13.0-051300rc7-generic I: /initrd.img is now a symlink to boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/zz-update-grub 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic # ls -latr / | grep -- '->' | grep boot | sort lrwxrwxrwx 1 root root 34 Jun 23 14:22 vmlinuz.old -> boot/vmlinuz-4.15.0-147-lowlatency lrwxrwxrwx 1 root root 37 Jun 23 14:22 initrd.img.old -> boot/initrd.img-4.15.0-147-lowlatency lrwxrwxrwx 1 root root 37 Jun 23 14:22 vmlinuz -> boot/vmlinuz-5.13.0-051300rc7-generic lrwxrwxrwx 1 root root 40 Jun 23 14:22 initrd.img -> boot/initrd.img-5.13.0-051300rc7-generic ** Tags added: verification-done-bionic -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage
[Kernel-packages] [Bug 1928700] Re: new postinst hook requires initramfs-tools
See verifications on https://bugs.launchpad.net/ubuntu/+source/linux- base/+bug/1929255 which cover this bug too. ** Tags removed: verification-failed-bionic ** Tags added: verification-done-bionic -- 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/1928700 Title: new postinst hook requires initramfs-tools Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [SRU Justification] == Impact == The new postinst hook from bug 1877088 currently requires initramfs-tools installed, or installing a kernel would fail. This happens for me on a builder chroot trying to build linux-meta of a derivative kernel. == Fix == The fix would be to skip running the script if update-initramfs is not available. The check was taken from the /etc/kernel/postinst.d/initramfs-tools script which has exactly that check at the beginning. == Testcase == Building linux-meta in a sbuild chroot which should again work without the messages about verifying links. Reinstalling a kernel on a system with update-initramfs existing should still print the messages. == Regression Potential == Systems with update-initramfs installed and initrd files might for some reason again fail to fix missing links. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1928700/+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
See verifications on https://bugs.launchpad.net/ubuntu/+source/linux- base/+bug/1929255 which cover this bug too. -- 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: Fix Committed Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Hirsute: Fix Committed Bug description: [Impact] * initrd link is not updated when using installkernel or "make install" from kernel sources. This leads to boot failure after installing a new kernel with mentioned methods because the kernel does not match initrd. * It's a regression because for Focal it was working before. * Issue was reproduced also on Bionic. * The proposed fixed by Stefan Bader adds a hook in /etc/kernel/postinst.d/ so installkernel will relink the initrd. The kernel DEB packages should not be affected. * The solution from Stefan (first patch) was tested by the bug reporter (niklas.schne...@ibm.com). [Test Plan] * Build a kernel * sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot * Check if /boot/initrd or /initrd symlink to the new initrd [Where problems could occur] * Installing kernel via: installkernel or "make install", so mostly kernel developer environments [Other info from developer] 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 1929255] Re: update-initrd-links creates incorrect symlinks
bionic: link_in_boot = yes # dpkg-query -W linux-base linux-base 4.5ubuntu1.6 # Two regular flavours # ls -latr /boot/ | grep -- '->' | sort lrwxrwxrwx 1 root root 26 Jun 23 14:08 vmlinuz.old -> vmlinuz-4.15.0-147-generic lrwxrwxrwx 1 root root 29 Jun 23 14:08 initrd.img.old -> initrd.img-4.15.0-147-generic lrwxrwxrwx 1 root root 29 Jun 23 14:10 vmlinuz -> vmlinuz-4.15.0-147-lowlatency lrwxrwxrwx 1 root root 32 Jun 23 14:10 initrd.img -> initrd.img-4.15.0-147-lowlatency # selfbuilt # installkernel 5.13.0-051300rc7-generic image/boot/vmlinuz-5.13.0-051300rc7-generic modules/boot/System.map-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic I: /boot/initrd.img.old is now a symlink to initrd.img-4.15.0-147-lowlatency I: /boot/initrd.img is now a symlink to initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/zz-update-grub 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic # ls -latr /boot/ | grep -- '->' | sort lrwxrwxrwx 1 root root 29 Jun 23 14:10 vmlinuz.old -> vmlinuz-4.15.0-147-lowlatency lrwxrwxrwx 1 root root 32 Jun 23 14:13 vmlinuz -> vmlinuz-5.13.0-051300rc7-generic lrwxrwxrwx 1 root root 32 Jun 23 14:14 initrd.img.old -> initrd.img-4.15.0-147-lowlatency lrwxrwxrwx 1 root root 35 Jun 23 14:14 initrd.img -> initrd.img-5.13.0-051300rc7-generic -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe :
[Kernel-packages] [Bug 1929255] Re: update-initrd-links creates incorrect symlinks
Hirsute: link_in_boot = yes # dpkg-query -W linux-base linux-base 4.5ubuntu5.2 # Two regular flavours # ls -latr /boot/ | grep -- '->' | sort lrwxrwxrwx 1 root root 25 Jun 23 10:46 vmlinuz.old -> vmlinuz-5.11.0-23-generic lrwxrwxrwx 1 root root 28 Jun 23 10:46 vmlinuz -> vmlinuz-5.11.0-23-lowlatency lrwxrwxrwx 1 root root 28 Jun 23 10:49 initrd.img.old -> initrd.img-5.11.0-23-generic lrwxrwxrwx 1 root root 31 Jun 23 10:48 initrd.img -> initrd.img-5.11.0-23-lowlatency # selfbuilt # installkernel 5.13.0-051300rc7-generic image/boot/vmlinuz-5.13.0-051300rc7-generic modules/boot/System.map-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic I: /boot/initrd.img.old is now a symlink to initrd.img-5.11.0-23-lowlatency I: /boot/initrd.img is now a symlink to initrd.img-5.13.0-051300rc7-generic # ls -latr /boot/ | grep -- '->' | sort lrwxrwxrwx 1 root root 28 Jun 23 10:46 vmlinuz.old -> vmlinuz-5.11.0-23-lowlatency lrwxrwxrwx 1 root root 31 Jun 23 10:52 initrd.img.old -> initrd.img-5.11.0-23-lowlatency lrwxrwxrwx 1 root root 32 Jun 23 10:52 vmlinuz -> vmlinuz-5.13.0-051300rc7-generic lrwxrwxrwx 1 root root 35 Jun 23 10:52 initrd.img -> initrd.img-5.13.0-051300rc7-generic -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
Hirsute: link_in_boot = no # dpkg-query -W linux-base linux-base 4.5ubuntu5.2 # Two regular flavours # ls -latr / | grep -- '->' | grep boot | sort lrwxrwxrwx 1 root root 30 Jun 23 10:58 vmlinuz.old -> boot/vmlinuz-5.11.0-23-generic lrwxrwxrwx 1 root root 33 Jun 23 10:58 initrd.img.old -> boot/initrd.img-5.11.0-23-generic lrwxrwxrwx 1 root root 33 Jun 23 11:00 vmlinuz -> boot/vmlinuz-5.11.0-23-lowlatency lrwxrwxrwx 1 root root 36 Jun 23 11:00 initrd.img -> boot/initrd.img-5.11.0-23-lowlatency # selfbuilt # installkernel 5.13.0-051300rc7-generic image/boot/vmlinuz-5.13.0-051300rc7-generic modules/boot/System.map-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc7-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc7-generic /boot/vmlinuz-5.13.0-051300rc7-generic I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.11.0-23-lowlatency I: /initrd.img.old is now a symlink to boot/initrd.img-5.11.0-23-lowlatency I: /vmlinuz is now a symlink to boot/vmlinuz-5.13.0-051300rc7-generic I: /initrd.img is now a symlink to boot/initrd.img-5.13.0-051300rc7-generic # ls -latr / | grep -- '->' | grep boot | sort lrwxrwxrwx 1 root root 33 Jun 23 11:12 vmlinuz.old -> boot/vmlinuz-5.11.0-23-lowlatency lrwxrwxrwx 1 root root 36 Jun 23 11:12 initrd.img.old -> boot/initrd.img-5.11.0-23-lowlatency lrwxrwxrwx 1 root root 37 Jun 23 11:12 vmlinuz -> boot/vmlinuz-5.13.0-051300rc7-generic lrwxrwxrwx 1 root root 40 Jun 23 11:12 initrd.img -> boot/initrd.img-5.13.0-051300rc7-generic ** Tags removed: regression-proposed ** Tags added: verification-done-hirsute -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to:
[Kernel-packages] [Bug 1932582] Re: Implement support for Intel SGX
Notice(queuebot): Unapproved: linux-base (hirsute-proposed/main) [4.5ubuntu5.2 => 4.5ubuntu5.3] -- 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/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Committed Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: In Progress Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Committed Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1932582] Re: Implement support for Intel SGX
Notice(queuebot): Unapproved: linux-base (focal-proposed/main) [4.5ubuntu3.5 => 4.5ubuntu3.6] -- 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/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Committed Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: In Progress Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Committed Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1932582] Re: Implement support for Intel SGX
** Changed in: linux-base (Ubuntu Impish) 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/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Committed Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: In Progress Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: In Progress Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Committed Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1932329] Re: Benchmark if we can compress kernel modules
I like smaller install size. In many cases we boot without initrd by default (gcp, azure, aws, kvm). Does it then make sense to enable this for the cloud kernels? I ponder, if i can hack initramfs-tools to append compressed kernel modules as an uncompressed cpio archive to the initramfs, instead of having it together with the userspace bits all compressed together. Separately, are the modules signed, then compressed, or compressed then signed? Cause the other alternative is to decompress the modules whilst including in the initramfs. That way we should get unchanged initrd sizes. So I guess I need to hack initramfs-tools more. -- 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/1932329 Title: Benchmark if we can compress kernel modules Status in linux package in Ubuntu: In Progress Bug description: Symbol: MODULE_COMPRESS_ZSTD [=n] Type : bool = Impacts to measure and observe = == Disk space == * Inspect linux-modules-* and linux-modules-extra* deb package Installed-Size and Download-Size changes, i.e. $ apt show linux-modules-5.8.0-53-generic linux-modules- extra-5.8.0-53-generic | grep -e Package: -e Size: Package: linux-modules-5.8.0-53-generic Installed-Size: 81.5 MB Download-Size: 15.5 MB Package: linux-modules-extra-5.8.0-53-generic Installed-Size: 215 MB Download-Size: 41.5 MB In theory, there should not be a significant change in the Download- size. It is desired that there is a significant reduction in Installed-Size. Modules take up about 300MB and normally one has upto three kernel version installed, resulting in about of 1GB of disk space that one constantly pays for. == Boot Speed == In theory, boot speed may either improve or regress. It depends if disk IO is slower than decompression speed, meaning loading compressed modules is faster. Also one has to observe the changes in the initrd size. zstd(zstd) compression may result in slight growth, which shouldn't impact boot speed too much. = Outcomes = If installed size savings can be achieved without regressing bootspeed we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932329/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method
decompression speed only needs to be faster than i/o speed, once that is reached the best compression ratio results in the fastest bootspped. for kernel image zstd is used with -22 --ultra, thus I can compare it with zlib -9. -- 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/1931725 Title: initramfs-tools & kernel: use zstd as the default compression method Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Bug description: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. Upstream submitted patch https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931725/+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 1932329] Re: Benchmark if we can compress kernel modules
Whilst download size is larger, it is at no additional cost to our end users, especially in the cloud. Majority of our clouds offer free transfers inside the availability zone for which mirrors are provided. Obviously it will increase the disk/cache storage size requirements of our mirrors. Our end users have about 3 sets of kernels installed on disk, for which they do pay more per GB between 2 to 12 cents (depending on technology IOPS / hdd / sda / nvme). All things being equal our users would choose larger download sizes to gain smaller install size. I assume that we have vastly larger install base, compared to number of our mirrors. I also hope that our install base is not larger than the total bandwidth available of our mirrors, such that this switch would cause collapse of our mirror network. I also notice that kernel uses default options for zstd module compression, instead of using -19 like it recommends for the initrds. I also notice that kmod in focal doesn't support zstd. Imho we should fix above before turning this on. -- 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/1932329 Title: Benchmark if we can compress kernel modules Status in linux package in Ubuntu: In Progress Bug description: Symbol: MODULE_COMPRESS_ZSTD [=n] Type : bool = Impacts to measure and observe = == Disk space == * Inspect linux-modules-* and linux-modules-extra* deb package Installed-Size and Download-Size changes, i.e. $ apt show linux-modules-5.8.0-53-generic linux-modules- extra-5.8.0-53-generic | grep -e Package: -e Size: Package: linux-modules-5.8.0-53-generic Installed-Size: 81.5 MB Download-Size: 15.5 MB Package: linux-modules-extra-5.8.0-53-generic Installed-Size: 215 MB Download-Size: 41.5 MB In theory, there should not be a significant change in the Download- size. It is desired that there is a significant reduction in Installed-Size. Modules take up about 300MB and normally one has upto three kernel version installed, resulting in about of 1GB of disk space that one constantly pays for. == Boot Speed == In theory, boot speed may either improve or regress. It depends if disk IO is slower than decompression speed, meaning loading compressed modules is faster. Also one has to observe the changes in the initrd size. zstd(zstd) compression may result in slight growth, which shouldn't impact boot speed too much. = Outcomes = If installed size savings can be achieved without regressing bootspeed we should enable CONFIG_MODULE_COMPRESS_ZSTD=y by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932329/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method
@cborntra v5.13 ubuntu kernel's s390 configuration with zstd -22 --ultra compression is 8.5 MB, whereas gzip -9 is 11M. Thus for gzip to win at bootspeed the decompression speed has to compensate for 2.5M of i/o and be faster than zstd. Unaccelerated decompression comparison still gives me faster decompression with less i/o with zstd compressed kernel image. At Canonical we still do not have z15 mainframe available for us to benchmark this. -- 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/1931725 Title: initramfs-tools & kernel: use zstd as the default compression method Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Bug description: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. Upstream submitted patch https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931725/+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 1932029] Re: Support builtin revoked certificates
https://lists.ubuntu.com/archives/kernel-team/2021-June/121362.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/1932029 Title: Support builtin revoked certificates Status in linux package in Ubuntu: New Bug description: [Impact] Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. Add support in our kernel configuration to have built-in revoked certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. Under UEFI Secureboot with lockdown, shim may attempt to communicate revoked certificates to the kernel and depending on how good EFI firmware is, this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older kernels that were signed with now revoked certificates, however one boots. [Test Plan] * Boot kernel directly, or just with grub, and without shim * Check that $ sudo keyctl list %:.blacklist Contains assymetric 2012 key. [Where problems could occur] * Derivative and per-arch kernels may need to revoke different keys, thus this should be evaluated on per arch & flavour basis as to which keys to revoke. [Other Info] * In theory, this only needs to be revoked on amd64 and arm64, but empty revocation list is not allowed by the kernel configury, thus at the moment revoking 2012 UEFI cert for all architectures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932029/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method
** Summary changed: - initramfs-tools: use zstd as the default compression method + initramfs-tools & kernel: use zstd as the default compression method ** Description changed: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). + + amd64 supports zstd, but s390x does not. Will use this bug to enable + zstd support on 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/1931725 Title: initramfs-tools & kernel: use zstd as the default compression method Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Bug description: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1931725/+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 1931242] [NEW] linux-uc20-efi: make it easy to build derivative kernel.efi
Public bug reported: linux-uc20-efi: make it easy to build derivative kernel.efi Currently debian/rules & debian.uc20-efi/control.stub are tightly coupled and hardcode the source package name (linux-uc20-efi), its relationship to linux-unsigned-image-* packages, and flavours to build kernel.efi apps for. Decouple those things a little bit, to make it easier to build derivative kernel.efi apps. 1) do not calculate KERNEL_SOURCE variable at all, as it is not needed 2) calculate flavours to build kernel.efi for, from build-deps This allows to create a derivative linux-blah-uc20-efi, and simply adjust debian.blah-uc20-efi/control.stub and produce correct signing tarballs for the correct required derivative flavour. ** 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/1931242 Title: linux-uc20-efi: make it easy to build derivative kernel.efi Status in linux package in Ubuntu: New Bug description: linux-uc20-efi: make it easy to build derivative kernel.efi Currently debian/rules & debian.uc20-efi/control.stub are tightly coupled and hardcode the source package name (linux-uc20-efi), its relationship to linux-unsigned-image-* packages, and flavours to build kernel.efi apps for. Decouple those things a little bit, to make it easier to build derivative kernel.efi apps. 1) do not calculate KERNEL_SOURCE variable at all, as it is not needed 2) calculate flavours to build kernel.efi for, from build-deps This allows to create a derivative linux-blah-uc20-efi, and simply adjust debian.blah-uc20-efi/control.stub and produce correct signing tarballs for the correct required derivative flavour. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1931242/+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 1932029] Re: Support builtin revoked certificates
** Description changed: + [Impact] + Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. Add support in our kernel configuration to have built-in certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. Under UEFI Secureboot with lockdown, shim may attempt to pass revoked certificates to the kernel and depending on how good EFI firmware is this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older kernels that were signed with now revoked certificates. + + + [Test Plan] + + * Boot kernel directly, or just with grub, and without shim + + * Check that + + $ sudo keyctl list %:.blacklist + + Contains assymetric 2012 key. + + [Where problems could occur] + + * Derivative and per-arch kernels may need to revoke different keys, + thus this should be evaluated on per arch & flavour basis as to which + keys to revoke. + + [Other Info] + + * In theory, this only needs to be revoked on amd64 and arm64, but empty revocation list is not allowed by the kernel configury, thus at the moment revoking 2012 UEFI cert for all architectures. ** Description changed: [Impact] Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. - Add support in our kernel configuration to have built-in certificates. + Add support in our kernel configuration to have built-in revoked + certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. - Under UEFI Secureboot with lockdown, shim may attempt to pass revoked - certificates to the kernel and depending on how good EFI firmware is - this may or may not succeed. + Under UEFI Secureboot with lockdown, shim may attempt to communicate + revoked certificates to the kernel and depending on how good EFI + firmware is, this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older - kernels that were signed with now revoked certificates. - + kernels that were signed with now revoked certificates, however one + boots. [Test Plan] - * Boot kernel directly, or just with grub, and without shim + * Boot kernel directly, or just with grub, and without shim - * Check that + * Check that $ sudo keyctl list %:.blacklist Contains assymetric 2012 key. [Where problems could occur] - * Derivative and per-arch kernels may need to revoke different keys, + * Derivative and per-arch kernels may need to revoke different keys, thus this should be evaluated on per arch & flavour basis as to which keys to revoke. [Other Info] - - * In theory, this only needs to be revoked on amd64 and arm64, but empty revocation list is not allowed by the kernel configury, thus at the moment revoking 2012 UEFI cert for all architectures. + + * In theory, this only needs to be revoked on amd64 and arm64, but + empty revocation list is not allowed by the kernel configury, thus at + the moment revoking 2012 UEFI cert for all architectures. -- 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/1932029 Title: Support builtin revoked certificates Status in linux package in Ubuntu: New Bug description: [Impact] Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. Add support in our kernel configuration to have built-in revoked certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. Under UEFI Secureboot with lockdown, shim may attempt to communicate revoked certificates to the kernel and depending on how good EFI firmware is, this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older kernels that were signed with now revoked certificates, however one boots. [Test Plan] * Boot kernel directly, or just with grub, and without shim * Check that $ sudo keyctl list %:.blacklist Contains assymetric 2012 key. [Where problems could occur] * Derivative and per-arch kernels may need to revoke different keys, thus this should be evaluated on per arch & flavour basis as to which keys to revoke. [Other Info] * In theory, this only needs to be revoked on amd64 and arm64, but empty revocation list is not allowed by the kernel configury, thus at the moment revoking 2012 UEFI cert for all architectures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932029/+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 1932029] [NEW] Support builtin revoked certificates
Public bug reported: Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. Add support in our kernel configuration to have built-in certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. Under UEFI Secureboot with lockdown, shim may attempt to pass revoked certificates to the kernel and depending on how good EFI firmware is this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older kernels that were signed with now revoked certificates. ** 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/1932029 Title: Support builtin revoked certificates Status in linux package in Ubuntu: New Bug description: Upstream linux kernel now supports configuring built-in revoked certificates for the .blacklist keyring. Add support in our kernel configuration to have built-in certificates. Revoke UEFI amd64 & arm64 2012 signing certificate. Under UEFI Secureboot with lockdown, shim may attempt to pass revoked certificates to the kernel and depending on how good EFI firmware is this may or may not succeed. By having these built-in, it will be prohibited to kexec file_load older kernels that were signed with now revoked certificates. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932029/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method
@ IBM can you please review the upstream patch and merge it into the the s390 tree ? https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u ** Description changed: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. + + Upstream submitted patch + https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u -- 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/1931725 Title: initramfs-tools & kernel: use zstd as the default compression method Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Bug description: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. Upstream submitted patch https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1931725/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
** Attachment added: "opal-2017-ppc64el.pem" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1903288/+attachment/5498448/+files/opal-2017-ppc64el.pem -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Incomplete Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
** Attachment added: "opal.esl" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1903288/+attachment/5498450/+files/opal.esl -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Incomplete Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
We should not add opal keys to the built_trusted_keys_keyring as that's not the purpose of these keys. We could add them direct to .platform or .ima keyrings, but it would be best to load them from firmware direct. Are the above attached keys & ESL available from the "powerpc:db"? -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Incomplete Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
** Attachment added: "opal-2019-ppc64el.pem" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1903288/+attachment/5498449/+files/opal-2019-ppc64el.pem -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Incomplete Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
@Nayna Jain @Daniel Hm but we have CONFIG_LOAD_PPC_KEYS=y already which I would expect to be the only thing that loads keys into .platform keyring which was enabled as part of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1866909 LTC-184073 . Which keys are present in firmware / get loaded into .platform because of that? I would have expected canonical keys to be loaded by that into the .platform keyring, or is that not the case? Can you please share contents of "powerpc:db"? Ideally it should contain Canonical's two OPAL signing certs. If canonical keys are not in "powerpc:db", does it make sense to then add the two Canonical keys to the .builtin_trusted_keys_keyring, and then link the whole keyring into .ima keyring? I will attach the two Canonical OPAL signing keys here, and the ESL for them. ** Changed in: linux (Ubuntu) Status: New => 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: Incomplete Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1914279] Re: linux from security may force reboots without complete dkms modules
virtualbox-hwe/6.1.16-dfsg-6ubuntu1.20.04.2 (s390x, ppc64el, armhf, arm64) -> is a false negative. virtualbox-hwe is only supported on amd64 i thought. https://autopkgtest.ubuntu.com/packages/v/virtualbox https://autopkgtest.ubuntu.com/packages/v/virtualbox-hwe Suggests that to be the case. -- 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/1914279 Title: linux from security may force reboots without complete dkms modules Status in acpi-call package in Ubuntu: New Status in apt package in Ubuntu: Invalid Status in backport-iwlwifi-dkms package in Ubuntu: New Status in bcmwl package in Ubuntu: New Status in dahdi-linux package in Ubuntu: New Status in dkms package in Ubuntu: Fix Released Status in dm-writeboost package in Ubuntu: New Status in evdi package in Ubuntu: New Status in gost-crypto package in Ubuntu: New Status in iptables-netflow package in Ubuntu: New Status in liblzf package in Ubuntu: New Status in lime-forensics package in Ubuntu: New Status in linux package in Ubuntu: Triaged Status in linux-meta package in Ubuntu: Triaged Status in lttng-modules package in Ubuntu: New Status in nvidia-graphics-drivers-340 package in Ubuntu: New Status in openafs package in Ubuntu: New Status in oss4 package in Ubuntu: New Status in r8168 package in Ubuntu: New Status in rtl8812au package in Ubuntu: New Status in sysdig package in Ubuntu: New Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Status in v4l2loopback package in Ubuntu: New Status in virtualbox package in Ubuntu: New Status in virtualbox-hwe package in Ubuntu: New Status in zfs-linux package in Ubuntu: New Status in acpi-call source package in Focal: Fix Committed Status in backport-iwlwifi-dkms source package in Focal: Fix Committed Status in bcmwl source package in Focal: Fix Committed Status in dahdi-linux source package in Focal: Fix Committed Status in dm-writeboost source package in Focal: Fix Committed Status in evdi source package in Focal: Fix Committed Status in gost-crypto source package in Focal: Fix Committed Status in iptables-netflow source package in Focal: Fix Committed Status in liblzf source package in Focal: Fix Committed Status in lime-forensics source package in Focal: Fix Committed Status in lttng-modules source package in Focal: Fix Committed Status in nvidia-graphics-drivers-340 source package in Focal: Fix Committed Status in oss4 source package in Focal: Fix Committed Status in r8168 source package in Focal: Fix Committed Status in rtl8812au source package in Focal: Fix Committed Status in sysdig source package in Focal: Fix Committed Status in v4l2loopback source package in Focal: Fix Committed Status in virtualbox source package in Focal: Fix Committed Status in virtualbox-hwe source package in Focal: Fix Committed Status in zfs-linux source package in Focal: Fix Committed Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1914279/+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 1914279] Re: linux from security may force reboots without complete dkms modules
** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- 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/1914279 Title: linux from security may force reboots without complete dkms modules Status in acpi-call package in Ubuntu: Fix Released Status in apt package in Ubuntu: Invalid Status in backport-iwlwifi-dkms package in Ubuntu: Fix Released Status in bcmwl package in Ubuntu: Fix Released Status in dahdi-linux package in Ubuntu: Fix Released Status in dkms package in Ubuntu: Fix Released Status in dm-writeboost package in Ubuntu: Fix Released Status in evdi package in Ubuntu: Fix Released Status in gost-crypto package in Ubuntu: Fix Released Status in iptables-netflow package in Ubuntu: Fix Released Status in liblzf package in Ubuntu: Fix Released Status in lime-forensics package in Ubuntu: Fix Released Status in linux package in Ubuntu: Triaged Status in linux-meta package in Ubuntu: Triaged Status in lttng-modules package in Ubuntu: Fix Released Status in nvidia-graphics-drivers-340 package in Ubuntu: Fix Released Status in openafs package in Ubuntu: New Status in oss4 package in Ubuntu: Fix Released Status in r8168 package in Ubuntu: Fix Released Status in rtl8812au package in Ubuntu: Fix Released Status in sysdig package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Status in v4l2loopback package in Ubuntu: Fix Released Status in virtualbox package in Ubuntu: Fix Released Status in virtualbox-hwe package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Fix Released Status in acpi-call source package in Focal: Fix Committed Status in backport-iwlwifi-dkms source package in Focal: Fix Committed Status in bcmwl source package in Focal: Fix Committed Status in dahdi-linux source package in Focal: Fix Committed Status in dm-writeboost source package in Focal: Fix Committed Status in evdi source package in Focal: Fix Committed Status in gost-crypto source package in Focal: Fix Committed Status in iptables-netflow source package in Focal: Fix Committed Status in liblzf source package in Focal: Fix Committed Status in lime-forensics source package in Focal: Fix Committed Status in lttng-modules source package in Focal: Fix Committed Status in nvidia-graphics-drivers-340 source package in Focal: Fix Committed Status in oss4 source package in Focal: Fix Committed Status in r8168 source package in Focal: Fix Committed Status in rtl8812au source package in Focal: Fix Committed Status in sysdig source package in Focal: Fix Committed Status in v4l2loopback source package in Focal: Fix Committed Status in virtualbox source package in Focal: Fix Committed Status in virtualbox-hwe source package in Focal: Fix Committed Status in zfs-linux source package in Focal: Fix Committed Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1914279/+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 1928679] [NEW] Support importing mokx keys into revocation list from the mok table
*** This bug is a security vulnerability *** Public security bug reported: [Impact] * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. * However, it only does so by reading MokListXRT efi variable. * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table * The above is known as CVE-2020-26541 * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. [Test Plan] * Boot kernel with 15.4 based Ubuntu shim * Install keyutils package * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. [Where problems could occur] * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI variable storage space (pre-4MB). [Other Info] * The patches to fix the above have been submitted upstream https://lore.kernel.org/keyrings/20210512153100.285169-1-dimitri.led...@canonical.com/ https://lore.kernel.org/keyrings/20210512110302.262104-1-dimitri.led...@canonical.com/ This will now be submitted as SAUCE patches for the Ubuntu UNSTABLE kernel, until accepted upstream. ** Affects: linux (Ubuntu) Importance: Undecided Status: Confirmed ** Summary changed: - Supporting importing dbx keys into revocation list from mok table + Support importing mokx keys into revocation list from the mok table ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-26541 ** Information type changed from Public to Public Security ** Changed in: linux (Ubuntu) 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/1928679 Title: Support importing mokx keys into revocation list from the mok table Status in linux package in Ubuntu: Confirmed Bug description: [Impact] * Ubuntu's 15.4 based shim ships a very large vendor-dbx (aka mokx) which revokes many Ubuntu kernel hashes and 2012 signing key. * Kernel should import those into it's %:.blacklist keyring such that it prohibits signed kexec of the revoked kernels. * v5.13-rc1 kernel has learned how to import mokx and how to import full certs into the %:.blacklist keyring. * However, it only does so by reading MokListXRT efi variable. * Due to the large size of Ubuntu's vendor-dbx, shim does not create MokListXRT efi variable, but instead creates MokListXRT1 MokListXRT2 MokListXRT3 which currently v5.13-rc1 kernel cannot read. Shim also exposes MokListXRT via mokvar table, which is easier to parse and contains all the revocations in full. Kernel needs a patch to read MokListXRT via mokvar table. * We have two options on how to proceed from here, either we include the same hashes and certs as our vendordbx in in the kernel as revocation list, or we fix kernel to read MokListXRT via mokvar table * The above is known as CVE-2020-26541 * Separately it would be nice to add informational dmesg messages when revoking signing certificates, as a good indication that signing key rotation events have happened and have been applied correctly. [Test Plan] * Boot kernel with 15.4 based Ubuntu shim * Install keyutils package * Execute $ sudo keyctl list %:.blacklist it should list in exccess of 300+ hash entries. It also must list assymetric Canonical signing key from 2012. * Separately check dmesg to observe that asymmetric canonical signing key from 2012 is revoked. [Where problems could occur] * EFI variable storage can be full thus preventing shim to mirror efivars and the moktable. On decent hardware this should not happen, but has been observed to be corrupted on some older EDKII based OVMF instances with small EFI
[Kernel-packages] [Bug 1923162] Re: riscv64 images fail to boot in qemu
** Changed in: u-boot (Ubuntu) Status: Fix Released => New ** Changed in: u-boot (Ubuntu Hirsute) Status: Fix Released => Triaged ** Changed in: u-boot (Ubuntu Hirsute) Status: Triaged => New ** Changed in: u-boot (Ubuntu) Importance: Critical => Undecided ** Also affects: u-boot (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: u-boot-menu (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux-riscv (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-riscv (Ubuntu Focal) Status: New => Invalid ** Changed in: u-boot-menu (Ubuntu Focal) Status: New => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1923162 Title: riscv64 images fail to boot in qemu Status in linux-riscv package in Ubuntu: Invalid Status in u-boot package in Ubuntu: New Status in u-boot-menu package in Ubuntu: Fix Released Status in linux-riscv source package in Focal: Invalid Status in u-boot source package in Focal: New Status in u-boot-menu source package in Focal: Invalid Status in linux-riscv source package in Hirsute: Invalid Status in u-boot source package in Hirsute: New Status in u-boot-menu source package in Hirsute: Fix Released Bug description: When booting v5.11 based riscv unmatched image in qemu with uboot, it fails to boot. When booting v5.11 based riscv unmatched kernel+initrd directly, it boots fine. Somehow, it seems that u-boot fails to correctly load & start v5.11 kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1923162/+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 1914279] Re: linux from security may force reboots without complete dkms modules
sru-release comments: virtualbox-hwe/6.1.16-dfsg-6ubuntu1.20.04.2 (s390x, ppc64el, armhf, arm64) -> autopkgtest failures are a false negative. It only is built and supported on amd64 sysdig/riscv64 - ftbfs is not a regression, never built on riscv64 in focal zfs-linux/riscv64 - ftbfs is not a regression, never built on riscv64 in focal iptables-netflow - needs 3 more days to age Thus everything is ready to be released to -updates & -security ** Changed in: acpi-call (Ubuntu) Status: New => Fix Released ** Changed in: backport-iwlwifi-dkms (Ubuntu) Status: New => Fix Released ** Changed in: zfs-linux (Ubuntu) Status: New => Fix Released ** Changed in: virtualbox-hwe (Ubuntu) Status: New => Fix Released ** Changed in: virtualbox (Ubuntu) Status: New => Fix Released ** Changed in: v4l2loopback (Ubuntu) Status: New => Fix Released ** Changed in: sysdig (Ubuntu) Status: New => Fix Released ** Changed in: rtl8812au (Ubuntu) Status: New => Fix Released ** Changed in: r8168 (Ubuntu) Status: New => Fix Released ** Changed in: oss4 (Ubuntu) Status: New => Fix Released ** Changed in: nvidia-graphics-drivers-340 (Ubuntu) Status: New => Fix Released ** Changed in: lttng-modules (Ubuntu) Status: New => Fix Released ** Changed in: lime-forensics (Ubuntu) Status: New => Fix Released ** Changed in: liblzf (Ubuntu) Status: New => Fix Released ** Changed in: iptables-netflow (Ubuntu) Status: New => Fix Released ** Changed in: gost-crypto (Ubuntu) Status: New => Fix Released ** Changed in: evdi (Ubuntu) Status: New => Fix Released ** Changed in: dm-writeboost (Ubuntu) Status: New => Fix Released ** Changed in: dahdi-linux (Ubuntu) Status: New => Fix Released ** Changed in: bcmwl (Ubuntu) Status: New => Fix Released -- 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/1914279 Title: linux from security may force reboots without complete dkms modules Status in acpi-call package in Ubuntu: Fix Released Status in apt package in Ubuntu: Invalid Status in backport-iwlwifi-dkms package in Ubuntu: Fix Released Status in bcmwl package in Ubuntu: Fix Released Status in dahdi-linux package in Ubuntu: Fix Released Status in dkms package in Ubuntu: Fix Released Status in dm-writeboost package in Ubuntu: Fix Released Status in evdi package in Ubuntu: Fix Released Status in gost-crypto package in Ubuntu: Fix Released Status in iptables-netflow package in Ubuntu: Fix Released Status in liblzf package in Ubuntu: Fix Released Status in lime-forensics package in Ubuntu: Fix Released Status in linux package in Ubuntu: Triaged Status in linux-meta package in Ubuntu: Triaged Status in lttng-modules package in Ubuntu: Fix Released Status in nvidia-graphics-drivers-340 package in Ubuntu: Fix Released Status in openafs package in Ubuntu: New Status in oss4 package in Ubuntu: Fix Released Status in r8168 package in Ubuntu: Fix Released Status in rtl8812au package in Ubuntu: Fix Released Status in sysdig package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Status in v4l2loopback package in Ubuntu: Fix Released Status in virtualbox package in Ubuntu: Fix Released Status in virtualbox-hwe package in Ubuntu: Fix Released Status in zfs-linux package in Ubuntu: Fix Released Status in acpi-call source package in Focal: Fix Committed Status in backport-iwlwifi-dkms source package in Focal: Fix Committed Status in bcmwl source package in Focal: Fix Committed Status in dahdi-linux source package in Focal: Fix Committed Status in dm-writeboost source package in Focal: Fix Committed Status in evdi source package in Focal: Fix Committed Status in gost-crypto source package in Focal: Fix Committed Status in iptables-netflow source package in Focal: Fix Committed Status in liblzf source package in Focal: Fix Committed Status in lime-forensics source package in Focal: Fix Committed Status in lttng-modules source package in Focal: Fix Committed Status in nvidia-graphics-drivers-340 source package in Focal: Fix Committed Status in oss4 source package in Focal: Fix Committed Status in r8168 source package in Focal: Fix Committed Status in rtl8812au source package in Focal: Fix Committed Status in sysdig source package in Focal: Fix Committed Status in v4l2loopback source package in Focal: Fix Committed Status in virtualbox source package in Focal: Fix Committed Status in virtualbox-hwe source package in Focal: Fix Committed Status in zfs-linux source package in Focal: Fix Committed Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in-
[Kernel-packages] [Bug 1923162] Re: riscv64 images fail to boot in qemu
** Description changed: - When booting v5.11 based riscv unmatched image in qemu with uboot, it - fails to boot. + [Impact] - When booting v5.11 based riscv unmatched kernel+initrd directly, it - boots fine. + * u-boot may crash when attempting to boot extlinux.conf which + specifies fdtdir; the given u-boot config doesn't specify a dtb filename + to load; autodetection tries to make one up using $soc & $board + variables; and if one or both of them are not set (as it is the case for + qemu) it would crash. Fix this crash by doing validation / checking when + quering for $soc & $board variables in autodetectionn. - Somehow, it seems that u-boot fails to correctly load & start v5.11 - kernel. + [Test Plan] + + * Use qemu & uboot produced by the build that fixes this bug report + properly and attempt to boot hirsute's riscv64+unmatched image. + + * It should boot correctly without a crash / qemu backtrace. + + [Where problems could occur] + + * This patch is bein upstreamed. If one is using external uboot (i.e. + provided by some other vendor) it may still crash when trying to boot + Ubuntu's riscv64 rootfs or cloud image. + + [Other Info] + + * Patch is being reviewed upstream https://lists.denx.de/pipermail/u-boot/2021-May/449176.html ** Changed in: u-boot (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1923162 Title: riscv64 images fail to boot in qemu Status in linux-riscv package in Ubuntu: Invalid Status in u-boot package in Ubuntu: Fix Committed Status in u-boot-menu package in Ubuntu: Fix Released Status in linux-riscv source package in Focal: Invalid Status in u-boot source package in Focal: New Status in u-boot-menu source package in Focal: Invalid Status in linux-riscv source package in Hirsute: Invalid Status in u-boot source package in Hirsute: New Status in u-boot-menu source package in Hirsute: Fix Released Bug description: [Impact] * u-boot may crash when attempting to boot extlinux.conf which specifies fdtdir; the given u-boot config doesn't specify a dtb filename to load; autodetection tries to make one up using $soc & $board variables; and if one or both of them are not set (as it is the case for qemu) it would crash. Fix this crash by doing validation / checking when quering for $soc & $board variables in autodetectionn. [Test Plan] * Use qemu & uboot produced by the build that fixes this bug report properly and attempt to boot hirsute's riscv64+unmatched image. * It should boot correctly without a crash / qemu backtrace. [Where problems could occur] * This patch is bein upstreamed. If one is using external uboot (i.e. provided by some other vendor) it may still crash when trying to boot Ubuntu's riscv64 rootfs or cloud image. [Other Info] * Patch is being reviewed upstream https://lists.denx.de/pipermail/u-boot/2021-May/449176.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1923162/+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 1929255] Re: update-initrd-links creates incorrect symlinks
On a given system we can have the following symlinks
/vmlinuz.old -> boot/vmlinuz-4.15.0-144-lowlatency
/vmlinuz -> boot/vmlinuz-4.15.0-144-generic
/boot/vmlinuz.old -> vmlinuz-4.15.0-144-lowlatency
/boot/vmlinuz -> vmlinuz-4.15.0-144-generic
which is controlled by /etc/kernel-img.conf setting link_in_boot. The
compiled-in default, and the setting that installers set has changed.
Thus depending which release one installed either cases might be
present.
And they should all work.
Testing the proposed patch:
linknames() {
tgt_kernel="$1"
echo old "initrd.img${tgt_kernel#vmlinu?}"
echo new "${tgt_kernel%/*}/initrd.img${tgt_kernel#*vmlinu?}"
}
linknames boot/vmlinuz-5.11
linknames vmlinuz-5.11
produces
old initrd.imgboot/vmlinuz-5.11
new boot/initrd.img-5.11
old initrd.img-5.11
new vmlinuz-5.11/initrd.img-5.11
meaning it fixes the case of link_in_boot = no; but regresses the
link_in_boot = yes case.
--
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/1929255
Title:
update-initrd-links creates incorrect symlinks
Status in linux-base package in Ubuntu:
Confirmed
Status in linux-base source package in Bionic:
Confirmed
Bug description:
## Problem description
Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script
incorrectly detects symbolic links targets and then creates malformed
(hence broken) ones instead:
/initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic
/initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic
while it should actually be:
/initrd.img -> boot/initrd.img-5.3.0-53-generic
/initrd.img.old -> boot/initrd.img-5.3.0-53-generic
The problem appeared with the release of the version 4.5ubuntu1.5 of
the linux-base package, which made this script executable.
## Solution
A solution is proposed through the attached patch file.
## System information
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Uname: Linux 5.3.0-53-generic x86_64
## Package information
Package: linux-base 4.5ubuntu1.5
PackageArchitecture: all
SourcePackage: linux-base
Tags: bionic package-from-proposed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
linux-update-symlinks install 4.15.0-144-generic
/boot/vmlinuz-4.15.0-144-generic => generates correct symlinks for
vmlinuz{.old} with both link_in_boot and without link_in_boot.
I am confused how come Debian kernels call linux-update-symlinks and
Ubuntu kernels (and upstream) do not.
--
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/1929255
Title:
update-initrd-links creates incorrect symlinks
Status in linux-base package in Ubuntu:
Confirmed
Status in linux-base source package in Bionic:
Confirmed
Bug description:
## Problem description
Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script
incorrectly detects symbolic links targets and then creates malformed
(hence broken) ones instead:
/initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic
/initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic
while it should actually be:
/initrd.img -> boot/initrd.img-5.3.0-53-generic
/initrd.img.old -> boot/initrd.img-5.3.0-53-generic
The problem appeared with the release of the version 4.5ubuntu1.5 of
the linux-base package, which made this script executable.
## Solution
A solution is proposed through the attached patch file.
## System information
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Uname: Linux 5.3.0-53-generic x86_64
## Package information
Package: linux-base 4.5ubuntu1.5
PackageArchitecture: all
SourcePackage: linux-base
Tags: bionic package-from-proposed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
But we do call linux-update-symlinks in the maintainer scripts. why doesn't installkernel call that, horum. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Bug description: ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. ## Solution A solution is proposed through the attached patch file. ## System information Description: Ubuntu 18.04.5 LTS Release: 18.04 Uname: Linux 5.3.0-53-generic x86_64 ## Package information Package: linux-base 4.5ubuntu1.5 PackageArchitecture: all SourcePackage: linux-base Tags: bionic package-from-proposed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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
Ubuntu Kernels in their postinst call linux-update-symlinks $change $version $image_path to setup correct links. This was not done by installkernel script, and a broken xx-update- initrd-links script is being added to postinst.d that does not correctly handle link_in_boot setting and breaks upgrades. imho installkernel script should call linux-update-symlinks just like our own linux-image kernels do in the postinst. ** Tags added: verification-failed-focal verification-failed-hirsute -- 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: Fix Committed Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Hirsute: Fix Committed Bug description: [Impact] * initrd link is not updated when using installkernel or "make install" from kernel sources. This leads to boot failure after installing a new kernel with mentioned methods because the kernel does not match initrd. * It's a regression because for Focal it was working before. * Issue was reproduced also on Bionic. * The proposed fixed by Stefan Bader adds a hook in /etc/kernel/postinst.d/ so installkernel will relink the initrd. The kernel DEB packages should not be affected. * The solution from Stefan (first patch) was tested by the bug reporter (niklas.schne...@ibm.com). [Test Plan] * Build a kernel * sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot * Check if /boot/initrd or /initrd symlink to the new initrd [Where problems could occur] * Installing kernel via: installkernel or "make install", so mostly kernel developer environments [Other info from developer] 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:
[Kernel-packages] [Bug 1929255] Re: update-initrd-links creates incorrect symlinks
I'm also not sure why that script exists at all in the current form. I would have thought we could switch to linux package themselves to call linux-update-symlinks like it is done in debian. Or at least not reimplement the wheel and just call linux-update- symlinks directly. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Bug description: ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. ## Solution A solution is proposed through the attached patch file. ## System information Description: Ubuntu 18.04.5 LTS Release: 18.04 Uname: Linux 5.3.0-53-generic x86_64 ## Package information Package: linux-base 4.5ubuntu1.5 PackageArchitecture: all SourcePackage: linux-base Tags: bionic package-from-proposed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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
Possibly a regression is being reported https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255 Please investigate, and if that needs fixing, please take appropriate action. If determined to not be a regression, please remove the validation-failed tags. ** Tags added: verification-failed-bionic -- 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: Fix Committed Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Hirsute: Fix Committed Bug description: [Impact] * initrd link is not updated when using installkernel or "make install" from kernel sources. This leads to boot failure after installing a new kernel with mentioned methods because the kernel does not match initrd. * It's a regression because for Focal it was working before. * Issue was reproduced also on Bionic. * The proposed fixed by Stefan Bader adds a hook in /etc/kernel/postinst.d/ so installkernel will relink the initrd. The kernel DEB packages should not be affected. * The solution from Stefan (first patch) was tested by the bug reporter (niklas.schne...@ibm.com). [Test Plan] * Build a kernel * sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot * Check if /boot/initrd or /initrd symlink to the new initrd [Where problems could occur] * Installing kernel via: installkernel or "make install", so mostly kernel developer environments [Other info from developer] 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 1928700] Re: new postinst hook requires initramfs-tools
Possibly a regression is being reported https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255 Please investigate, and if that needs fixing, please take appropriate action. If determined to not be a regression, please remove the validation-failed tags. ** Tags removed: verification-done-bionic ** Tags added: verification-failed-bionic -- 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/1928700 Title: new postinst hook requires initramfs-tools Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux-base source package in Hirsute: Fix Committed Status in linux-base source package in Impish: Fix Released Bug description: [SRU Justification] == Impact == The new postinst hook from bug 1877088 currently requires initramfs-tools installed, or installing a kernel would fail. This happens for me on a builder chroot trying to build linux-meta of a derivative kernel. == Fix == The fix would be to skip running the script if update-initramfs is not available. The check was taken from the /etc/kernel/postinst.d/initramfs-tools script which has exactly that check at the beginning. == Testcase == Building linux-meta in a sbuild chroot which should again work without the messages about verifying links. Reinstalling a kernel on a system with update-initramfs existing should still print the messages. == Regression Potential == Systems with update-initramfs installed and initrd files might for some reason again fail to fix missing links. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1928700/+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 1929255] Re: update-initrd-links creates incorrect symlinks
** Tags added: regresion-proposed regression-update -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Bug description: ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. ## Solution A solution is proposed through the attached patch file. ## System information Description: Ubuntu 18.04.5 LTS Release: 18.04 Uname: Linux 5.3.0-53-generic x86_64 ## Package information Package: linux-base 4.5ubuntu1.5 PackageArchitecture: all SourcePackage: linux-base Tags: bionic package-from-proposed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
# dpkg-query -W initramfs-tools linux-base initramfs-tools 0.140ubuntu4 linux-base 4.5ubuntu8 # cat /etc/kernel-img.conf do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no # ls -latr / | grep '> boot' # apt install linux-generic # ls -l / | grep '> boot' lrwxrwxrwx 1 root root 33 May 27 13:12 initrd.img -> boot/initrd.img-5.11.0-16-generic lrwxrwxrwx 1 root root 33 May 27 13:12 initrd.img.old -> boot/initrd.img-5.11.0-16-generic lrwxrwxrwx 1 root root 30 May 27 13:12 vmlinuz -> boot/vmlinuz-5.11.0-16-generic lrwxrwxrwx 1 root root 30 May 27 13:12 vmlinuz.old -> boot/vmlinuz-5.11.0-16-generic # apt install linux-lowlatency # ls -l / | grep '> boot' lrwxrwxrwx 1 root root 36 May 27 13:17 initrd.img -> boot/initrd.img-5.11.0-16-lowlatency lrwxrwxrwx 1 root root 33 May 27 13:12 initrd.img.old -> boot/initrd.img-5.11.0-16-generic lrwxrwxrwx 1 root root 33 May 27 13:17 vmlinuz -> boot/vmlinuz-5.11.0-16-lowlatency lrwxrwxrwx 1 root root 30 May 27 13:12 vmlinuz.old -> boot/vmlinuz-5.11.0-16-generic Grab a "self-built" kernel # wget https://kernel.ubuntu.com/~kernel-ppa/mainline/daily/2021-05-26/amd64/linux-image-unsigned-5.13.0-051300rc3daily20210526-generic_5.13.0-051300rc3daily20210526.202105252209_amd64.deb # wget https://kernel.ubuntu.com/~kernel- ppa/mainline/daily/2021-05-26/amd64/linux- modules-5.13.0-051300rc3daily20210526-generic_5.13.0-051300rc3daily20210526.202105252209_amd64.deb # dpkg-deb -x linux-modules-5.13.0-051300rc3daily20210526-generic_5.13.0-051300rc3daily20210526.202105252209_amd64.deb linux/ # dpkg-deb -x linux-image-unsigned-5.13.0-051300rc3daily20210526-generic_5.13.0-051300rc3daily20210526.202105252209_amd64.deb linux/ # cp -r linux/lib/modules/5.13.0-051300rc3daily20210526-generic /lib/modules/ # installkernel 5.13.0-051300rc3daily202 10526-generic ./linux/boot/vmlinuz-5.13.0-051300rc3daily20210526-generic ./linux/boot/System.map-5.13.0-051300rc3daily20210526-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc3daily20210526-generic /boot/vmlinuz-5.13.0-051300rc3daily20210526-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc3daily20210526-generic /boot/vmlinuz-5.13.0-051300rc3daily20210526-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc3daily20210526-generic # ls -l / | grep '> boot' lrwxrwxrwx 1 root root 36 May 27 13:29 initrd.img -> boot/initrd.img-5.11.0-16-lowlatency lrwxrwxrwx 1 root root 33 May 27 13:33 initrd.img.old -> boot/initrd.img-5.11.0-16-generic lrwxrwxrwx 1 root root 33 May 27 13:29 vmlinuz -> boot/vmlinuz-5.11.0-16-lowlatency lrwxrwxrwx 1 root root 30 May 27 13:29 vmlinuz.old -> boot/vmlinuz-5.11.0-16-generic and fail Let's see what's wrong with my patch. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Status in linux-base source package in Focal: New Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: New Status in linux-base source package in Impish: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it
[Kernel-packages] [Bug 1929255] Re: update-initrd-links creates incorrect symlinks
** Patch added: "lp1929255.patch" https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+attachment/5500691/+files/lp1929255.patch ** Patch removed: "lp1929255.patch" https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+attachment/5500663/+files/lp1929255.patch -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Status in linux-base source package in Focal: New Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: New Status in linux-base source package in Impish: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
aha, my xx-update-initrd-links lost executable bit again. need to fix that up in my packaging. But also invalidates my previous test a bit. # installkernel 5.13.0-051300rc3daily20210526-generic ./linux/boot/vmlinuz-5.13.0-051300rc3daily20210526-generic ./linux/boot/System.map-5.13.0-051300rc3daily20210526-generic run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.13.0-051300rc3daily20210526-generic /boot/vmlinuz-5.13.0-051300rc3daily20210526-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.13.0-051300rc3daily20210526-generic /boot/vmlinuz-5.13.0-051300rc3daily20210526-generic update-initramfs: Generating /boot/initrd.img-5.13.0-051300rc3daily20210526-generic run-parts: executing /etc/kernel/postinst.d/xx-update-initrd-links 5.13.0-051300rc3daily20210526-generic /boot/vmlinuz-5.13.0-051300rc3daily20210526-generic I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.11.0-16-lowlatency I: /initrd.img.old is now a symlink to boot/initrd.img-5.11.0-16-lowlatency I: /vmlinuz is now a symlink to boot/vmlinuz-5.13.0-051300rc3daily20210526-generic I: /initrd.img is now a symlink to boot/initrd.img-5.13.0-051300rc3daily20210526-generic all is good. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Status in linux-base source package in Focal: New Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: New Status in linux-base source package in Impish: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
** Description changed: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. - [Test Plan] - * Install new linux-base and initramfs-tools + * Install new linux-base and initramfs-tools - * create /etc/kernel-img.conf with + * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes - * Install one kernel flavour, check that symlinks in /boot have sane targets - * Install another kernel, check that symlinks in /boot/ have sane targets + * Install one kernel flavour, check that symlinks in /boot have sane targets + * Install another kernel, check that symlinks in /boot/ have sane targets - * create a selfbuilt kernel and install it by calling installkernel + * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. - * Purge all kernel, and remove symlinks in /boot + * Purge all kernel, and remove symlinks in /boot - * Update /etc/kernel-img.conf to + * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no - * Install one kernel flavour, check that symlinks in / have sane targets - * Install another kernel, check that symlinks in / have sane targets - * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) + * Install one kernel flavour, check that symlinks in / have sane targets + * Install another kernel, check that symlinks in / have sane targets + * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) + + * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot + * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] - * The rewritten postinst.d script now simply mostly calls linux-update- + * The rewritten postinst.d script now simply mostly calls linux-update- links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. ** Also affects: linux-base (Ubuntu Impish) Importance: Undecided Status: Confirmed ** Also affects: linux-base (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux-base (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: linux-base (Ubuntu Groovy) Importance: Undecided Status: New -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Status in linux-base source package in Focal: New Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: New Status in linux-base source package in Impish: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets *
[Kernel-packages] [Bug 1929255] Re: update-initrd-links creates incorrect symlinks
Untested yet, but here is a proposed patch which hopefully will fix installkernel in all link_in_boot modes, without regressing anything. ** Patch added: "lp1929255.patch" https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+attachment/5500663/+files/lp1929255.patch -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Bug description: ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. ## Solution A solution is proposed through the attached patch file. ## System information Description: Ubuntu 18.04.5 LTS Release: 18.04 Uname: Linux 5.3.0-53-generic x86_64 ## Package information Package: linux-base 4.5ubuntu1.5 PackageArchitecture: all SourcePackage: linux-base Tags: bionic package-from-proposed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
** Description changed: + [Impact] + ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. - ## Solution - A solution is proposed through the attached patch file. + [Test Plan] - ## System information + * Install new linux-base and initramfs-tools - Description: Ubuntu 18.04.5 LTS - Release: 18.04 - Uname: Linux 5.3.0-53-generic x86_64 + * create /etc/kernel-img.conf with - ## Package information + do_symlinks = yes + do_bootloader = no + do_initrd = yes + link_in_boot = yes - Package: linux-base 4.5ubuntu1.5 - PackageArchitecture: all - SourcePackage: linux-base - Tags: bionic package-from-proposed + * Install one kernel flavour, check that symlinks in /boot have sane targets + * Install another kernel, check that symlinks in /boot/ have sane targets + + * create a selfbuilt kernel and install it by calling installkernel + (you can download kernel debs from kernel-ppa, and unpack them to + pretend one has self built it). and check that symlinks in /boot have + sane targets. + + * Purge all kernel, and remove symlinks in /boot + + * Update /etc/kernel-img.conf to + + do_symlinks = yes + do_bootloader = no + do_initrd = yes + link_in_boot = no + + * Install one kernel flavour, check that symlinks in / have sane targets + * Install another kernel, check that symlinks in / have sane targets + * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) + + [Where problems could occur] + + * The rewritten postinst.d script now simply mostly calls linux-update- + links like the normal linux-image postinst script does. One has to make + sure that .deb installations of kernels happens correctly and that + installkernel way of installing kernels happens correctly. Under + different kernel-img.conf settings. The previous incarnations of fixing + this and related issues did not account for the above cases and + codepaths. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for
[Kernel-packages] [Bug 1929255] Re: update-initrd-links creates incorrect symlinks
Redid the test case with initramfs-tools installed and the updated linux-base patch. Installed generic, links pointed at generic. Installed lowlatency, old pointed at generic and the current links pointed at lowlatency. Installed a kernel using installkernel script to /boot, old points at lowlatency and current points at custom installed kernel. # ls -l /boot/ | grep '>' lrwxrwxrwx 1 root root 48 May 28 10:02 initrd.img -> initrd.img-5.13.0-051300rc3daily20210526-generic lrwxrwxrwx 1 root root 31 May 28 10:02 initrd.img.old -> initrd.img-5.11.0-16-lowlatency lrwxrwxrwx 1 root root 45 May 28 10:02 vmlinuz -> vmlinuz-5.13.0-051300rc3daily20210526-generic lrwxrwxrwx 1 root root 28 May 28 09:51 vmlinuz.old -> vmlinuz-5.11.0-16-lowlatency -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Status in linux-base source package in Focal: New Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: New Status in linux-base source package in Impish: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1929255] Re: update-initrd-links creates incorrect symlinks
Testing again, but without initramfs-tools installed, and with kernel- img.conf set to do_initrd = yes and link_in_boot = no End result is this: # ls -l /vmlinu* /initrd.img* /boot/initrd.img* ls: cannot access '/boot/initrd.img*': No such file or directory lrwxrwxrwx 1 root root 53 May 28 10:30 /initrd.img -> boot/initrd.img-5.13.0-051300rc3daily20210526-generic lrwxrwxrwx 1 root root 50 May 28 10:30 /vmlinuz -> boot/vmlinuz-5.13.0-051300rc3daily20210526-generic lrwxrwxrwx 1 root root 33 May 28 10:30 /vmlinuz.old -> boot/vmlinuz-5.11.0-16-lowlatency initrd.img symlink from / is a dangling one. /vmlinuz* are correctly updated. initrd.img.old is not existant. This confirms that the revised postin.d snippet is working correctly and it doesn't matter if it is ordered before or after generating initrd. -- 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/1929255 Title: update-initrd-links creates incorrect symlinks Status in linux-base package in Ubuntu: Confirmed Status in linux-base source package in Bionic: Confirmed Status in linux-base source package in Focal: New Status in linux-base source package in Groovy: New Status in linux-base source package in Hirsute: New Status in linux-base source package in Impish: Confirmed Bug description: [Impact] ## Problem description Executing the `/etc/kernel/postinst.d/xx-update-initrd-links` script incorrectly detects symbolic links targets and then creates malformed (hence broken) ones instead: /initrd.img -> initrd.imgboot/vmlinuz-5.3.0-53-generic /initrd.img.old -> initrd.imgboot/vmlinuz-5.3.0-53-generic while it should actually be: /initrd.img -> boot/initrd.img-5.3.0-53-generic /initrd.img.old -> boot/initrd.img-5.3.0-53-generic The problem appeared with the release of the version 4.5ubuntu1.5 of the linux-base package, which made this script executable. [Test Plan] * Install new linux-base and initramfs-tools * create /etc/kernel-img.conf with do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = yes * Install one kernel flavour, check that symlinks in /boot have sane targets * Install another kernel, check that symlinks in /boot/ have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it). and check that symlinks in /boot have sane targets. * Purge all kernel, and remove symlinks in /boot * Update /etc/kernel-img.conf to do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no * Install one kernel flavour, check that symlinks in / have sane targets * Install another kernel, check that symlinks in / have sane targets * create a selfbuilt kernel and install it by calling installkernel (you can download kernel debs from kernel-ppa, and unpack them to pretend one has self built it) * remove all kernels, purge initramfs-tools, clean up symlinks in / and /boot * repeat all of the above, without having initramfs-tools installed. I.e. install kernels _without_ recommneds. [Where problems could occur] * The rewritten postinst.d script now simply mostly calls linux- update-links like the normal linux-image postinst script does. One has to make sure that .deb installations of kernels happens correctly and that installkernel way of installing kernels happens correctly. Under different kernel-img.conf settings. The previous incarnations of fixing this and related issues did not account for the above cases and codepaths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+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 1932163] Re: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
@cascardo for the focal's backport resurrecting focal's debian/changelog. See attached. ** Patch added: "sponsor.diff" https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1932163/+attachment/5509864/+files/sponsor.diff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932163 Title: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in evdi package in Ubuntu: Confirmed Status in linux-hwe-5.11 package in Ubuntu: Confirmed Status in evdi source package in Focal: In Progress Status in linux-hwe-5.11 source package in Focal: Confirmed Status in evdi source package in Hirsute: Confirmed Status in linux-hwe-5.11 source package in Hirsute: Confirmed Bug description: [Impact] focal users running latest hwe kernel, version 5.11, won't be able to use evdi-dkms. [Test case] Built evdi dkms and loaded the evdi module on 5.4, 5.8 and 5.11 kernels. [Potential regression] DisplayLink devices will stop working. -- This is a scripted bug report about ADT failures while running evdi tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/e/evdi/20210611_210228_7f0da@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/e/evdi/20210612_122245_bd52e@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/e/evdi/20210611_210028_038f3@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/e/evdi/20210611_205902_3dc65@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1932163/+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 1923638] Re: [FFe] evdi/1.7.0+dfsg-1ubuntu2 fails to build with linux 5.11
*** This bug is a duplicate of bug 1932163 *** https://bugs.launchpad.net/bugs/1932163 This bug should have straight away opened tasks against hirsute and focal. Because we do provide newer kernels on hirsute (self built, or installed from kernel teams mainline ppa). And because we do roll focal to newer kernels. https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1932163 got opened two months later, and the SRU to focal will now reference them both. Marking this bug report as duplicate of the SRU one, for more obvious SRU paper trail. ** This bug has been marked a duplicate of bug 1932163 evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1 -- 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/1923638 Title: [FFe] evdi/1.7.0+dfsg-1ubuntu2 fails to build with linux 5.11 Status in evdi package in Ubuntu: Fix Released Status in linux package in Ubuntu: Invalid Bug description: evdi-dkms in hirsute cannot be used with the 5.11 kernel in hirsute as it will fail to build. Upstream updates for 5.11 proved problematic, and a working set of updates became available in the upstream project only recently. Unfortunately these updates are difficult to backport due to upstream changes, and if they are backported the kernel team has no access to hardware to confirm that the backports function as intended. Therefore the safest course of action seems to be to move forward to the latest upstream evdi release plus they fixes for 5.11 from git, which has been tested by a number of evdi users already. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1923638/+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 1932163] Re: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
** Changed in: evdi (Ubuntu Hirsute) Status: Confirmed => In Progress ** Changed in: evdi (Ubuntu) Status: Confirmed => Fix Released ** Changed in: linux-hwe-5.11 (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932163 Title: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in evdi package in Ubuntu: Fix Released Status in linux-hwe-5.11 package in Ubuntu: Fix Released Status in evdi source package in Focal: In Progress Status in linux-hwe-5.11 source package in Focal: Confirmed Status in evdi source package in Hirsute: In Progress Status in linux-hwe-5.11 source package in Hirsute: Confirmed Bug description: [Impact] focal users running latest hwe kernel, version 5.11, won't be able to use evdi-dkms. [Test case] Built evdi dkms and loaded the evdi module on 5.4, 5.8 and 5.11 kernels. [Potential regression] DisplayLink devices will stop working. -- This is a scripted bug report about ADT failures while running evdi tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/e/evdi/20210611_210228_7f0da@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/e/evdi/20210612_122245_bd52e@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/e/evdi/20210611_210028_038f3@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/e/evdi/20210611_205902_3dc65@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1932163/+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 1932163] Re: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
** Description changed: [Impact] focal users running latest hwe kernel, version 5.11, won't be able to use evdi-dkms. [Test case] Built evdi dkms and loaded the evdi module on 5.4, 5.8 and 5.11 kernels. [Potential regression] DisplayLink devices will stop working. - -- This is a scripted bug report about ADT failures while running evdi tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/e/evdi/20210611_210228_7f0da@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/e/evdi/20210612_122245_bd52e@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/e/evdi/20210611_210028_038f3@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/e/evdi/20210611_205902_3dc65@/log.gz + + [Other] + + NB! dkms ftbfs fixes must be built in security, such that after SRU + process in -proposed & -updates it can be copied into -security pocket + too. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932163 Title: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in evdi package in Ubuntu: Fix Released Status in linux-hwe-5.11 package in Ubuntu: Fix Released Status in evdi source package in Focal: In Progress Status in linux-hwe-5.11 source package in Focal: Confirmed Status in evdi source package in Hirsute: In Progress Status in linux-hwe-5.11 source package in Hirsute: Confirmed Bug description: [Impact] focal users running latest hwe kernel, version 5.11, won't be able to use evdi-dkms. [Test case] Built evdi dkms and loaded the evdi module on 5.4, 5.8 and 5.11 kernels. [Potential regression] DisplayLink devices will stop working. -- This is a scripted bug report about ADT failures while running evdi tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/e/evdi/20210611_210228_7f0da@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/e/evdi/20210612_122245_bd52e@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/e/evdi/20210611_210028_038f3@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/e/evdi/20210611_205902_3dc65@/log.gz [Other] NB! dkms ftbfs fixes must be built in security, such that after SRU process in -proposed & -updates it can be copied into -security pocket too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1932163/+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 1932166] Re: openafs/1.8.4~pre1-1ubuntu2.1 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
** Description changed: [Impact] Openafs 1.8.4~pre1-1ubuntu2.1 FTBFS when built against Linux 5.11 - [Fix] Apply the attached debdiff (that is, in turn, a backport of upstream Linux build fixes), build the debs, install the dkms deb and build it against an installed 5.11 kernel: $ sudo dkms install openafs/1.8.4~pre1-1ubuntu2.1 -k $linux-5.11-version - [Regression potential] The previous DKMS didn't build at all against 5.11. -- This is a scripted bug report about ADT failures while running openafs tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/o/openafs/20210611_211122_e1866@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/o/openafs/20210612_124646_ae454@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/o/openafs/20210611_212209_cd7d4@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/o/openafs/20210611_210636_9cb1d@/log.gz + + [Other] + + NB! dkms ftbfs fixes must be built in security, such that after SRU + process in -proposed & -updates it can be copied into -security pocket + too. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932166 Title: openafs/1.8.4~pre1-1ubuntu2.1 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in linux-hwe-5.11 package in Ubuntu: New Status in openafs package in Ubuntu: Fix Released Status in linux-hwe-5.11 source package in Focal: New Status in openafs source package in Focal: In Progress Bug description: [Impact] Openafs 1.8.4~pre1-1ubuntu2.1 FTBFS when built against Linux 5.11 [Fix] Apply the attached debdiff (that is, in turn, a backport of upstream Linux build fixes), build the debs, install the dkms deb and build it against an installed 5.11 kernel: $ sudo dkms install openafs/1.8.4~pre1-1ubuntu2.1 -k $linux-5.11-version [Regression potential] The previous DKMS didn't build at all against 5.11. -- This is a scripted bug report about ADT failures while running openafs tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/o/openafs/20210611_211122_e1866@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/o/openafs/20210612_124646_ae454@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/o/openafs/20210611_212209_cd7d4@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/o/openafs/20210611_210636_9cb1d@/log.gz [Other] NB! dkms ftbfs fixes must be built in security, such that after SRU process in -proposed & -updates it can be copied into -security pocket too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-5.11/+bug/1932166/+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 1932173] Re: xtables-addons/3.9-1ubuntu0.2~20.04.1 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
** Description changed: [Impact] This is a scripted bug report about ADT failures while running xtables- addons tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/x/xtables-addons/20210611_210642_1c193@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/x/xtables-addons/20210612_124839_710ee@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/x/xtables-addons/20210611_211032_cbce4@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/x/xtables-addons/20210611_210646_8bf21@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/x/xtables-addons/20210611_210425_4d74a@/log.gz [Test Plan] sudo apt-get install xtables-addons-dkms [Where problems could occur] Run time regressions could occur due to compatibility changes required for linux-hwe-5.11. - [Other Info] + [Other] + + NB! dkms ftbfs fixes must be built in security, such that after SRU + process in -proposed & -updates it can be copied into -security pocket + too. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932173 Title: xtables-addons/3.9-1ubuntu0.2~20.04.1 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in linux-hwe-5.11 package in Ubuntu: New Status in xtables-addons package in Ubuntu: New Status in linux-hwe-5.11 source package in Focal: New Status in xtables-addons source package in Focal: Fix Committed Bug description: [Impact] This is a scripted bug report about ADT failures while running xtables-addons tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/x/xtables-addons/20210611_210642_1c193@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/x/xtables-addons/20210612_124839_710ee@/log.gz armhf: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/armhf/x/xtables-addons/20210611_211032_cbce4@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/x/xtables-addons/20210611_210646_8bf21@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/x/xtables-addons/20210611_210425_4d74a@/log.gz [Test Plan] sudo apt-get install xtables-addons-dkms [Where problems could occur] Run time regressions could occur due to compatibility changes required for linux-hwe-5.11. [Other] NB! dkms ftbfs fixes must be built in security, such that after SRU process in -proposed & -updates it can be copied into -security pocket too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-5.11/+bug/1932173/+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 1932081] Re: Disable hv-kvp-daemon.service on certain instance types
ubuntu@gen2:~$ dpkg-query -W linux-cloud-tools-common linux-cloud-tools-common5.4.0-79.88 ubuntu@gen2:~$ systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enab> Active: active (running) since Thu 2021-07-08 16:06:00 UTC; 1min 3s ago Main PID: 283 (hv_kvp_daemon) Tasks: 1 (limit: 8334) Memory: 3.2M CGroup: /system.slice/hv-kvp-daemon.service └─283 /usr/lib/linux-tools/5.8.0-1038-azure/hv_kvp_daemon -n Jul 08 16:06:00 gen2 systemd[1]: Started Hyper-V KVP Protocol Daemon. Jul 08 16:06:00 gen2 KVP[283]: KVP starting; pid is:283 Jul 08 16:06:00 gen2 KVP[283]: KVP LIC Version: 3.1 ubuntu@gen2:~$ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.8.0-1038-azure root=PARTUUID=14d21af5-beed-4a59-966b-cbcab58b7936 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 panic=-1 So with normal instances this service is still running. Upgraded to a different kernel ubuntu@gen2:~$ cat /proc/cmdline snapd_recovery_mode=cloudimg-rootfs console=tty1 console=ttyS0 earlyprintk=ttyS0 ubuntu@gen2:~$ systemctl status hv-kvp-daemon.service ● hv-kvp-daemon.service - Hyper-V KVP Protocol Daemon Loaded: loaded (/lib/systemd/system/hv-kvp-daemon.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2021-07-08 16:12:39 UTC; 1min 45s ago └─ ConditionKernelCommandLine=!snapd_recovery_mode was not met Jul 08 16:12:39 gen2 systemd[1]: Condition check resulted in Hyper-V KVP Protocol Daemon being skipped. And the service is not running on this other kernel type. This means that we are not regressing support for this service on stock instance type & kernel type; and correctly prevent running it on the other instance type & kernel type. No other series apart from focal support this yet, hence this is now verified. This change should remain in all other kernels, in case we enable using those kernels on this instance type. ** Tags removed: verification-needed-bionic verification-needed-focal verification-needed-groovy verification-needed-hirsute ** Tags added: verification-done-bionic verification-done-focal verification-done-groovy verification-done-hirsute -- 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/1932081 Title: Disable hv-kvp-daemon.service on certain instance types Status in linux package in Ubuntu: New Status in linux source package in Bionic: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: Fix Committed Status in linux source package in Hirsute: Fix Committed Bug description: [Impact] * Disable hv-kvp-daemon.service on certain instance types. As requested for some azure instance types, hv-kvp-daemon is prohibited from starting, and currently it takes a long time to come up and fail. Configure to disable the service on those instances. At the moment, we can key off kernel command line to detect those. [Test Plan] * Boot preview image in azure * Check that hv-kvp-daemon.service is not running [Where problems could occur] * The conditions/detection could have been more specific as to when the daemon is pointless to run. Thus key-off kernel commandline is good enough for now, but may require changes in the future. [Other Info] @ Kernel team, also see https://trello.com/c/JbomiFOe https://lists.ubuntu.com/archives/kernel-team/2021-June/121384.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932081/+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 1932168] Re: oss4/4.2-build2010-5ubuntu6~20.04.2 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
Building in security only bileto ppa $ dput ppa:ci-train-ppa-service/4601 oss4_4.2-build2010-5ubuntu6~20.04.3_source.changes D: Splitting host argument out of ppa:ci-train-ppa-service/4601. D: Setting host argument. Checking signature on .changes gpg: /tmp/oss4_4.2-build2010-5ubuntu6~20.04.3_source.changes: Valid signature from 9B8EC849D5EF70ED Checking signature on .dsc gpg: /tmp/oss4_4.2-build2010-5ubuntu6~20.04.3.dsc: Valid signature from 9B8EC849D5EF70ED Uploading to ppa (via sftp to ppa.launchpad.net): Uploading oss4_4.2-build2010-5ubuntu6~20.04.3.dsc: done. Uploading oss4_4.2-build2010-5ubuntu6~20.04.3.debian.tar.xz: done. Uploading oss4_4.2-build2010-5ubuntu6~20.04.3_source.buildinfo: done. Uploading oss4_4.2-build2010-5ubuntu6~20.04.3_source.changes: done. Successfully uploaded packages. ** Description changed: [Impact] oss4 dkms will fail to build on 5.11 kernels on focal, preventing users from using those modules on more recent kernels. [Test case] Install the package and make sure it builds. [Fix] Conditionally define a function that is not used on the Linux port when LICENSED_VERSION is undefined. [Fix risk] Licensed versions will fail to build, but we don't do those. Other ports should not fail as we only patch the Linux port. [Potential regression] The dkms package may still fail to build, install or load. Or sound might not work on systems that depend on oss4. --- This is a scripted bug report about ADT failures while running oss4 tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/o/oss4/20210611_210018_1dcc5@/log.gz + + [Other] + + NB! dkms ftbfs fixes must be built in security, such that after SRU + process in -proposed & -updates it can be copied into -security pocket + too. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932168 Title: oss4/4.2-build2010-5ubuntu6~20.04.2 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in linux-hwe-5.11 package in Ubuntu: New Status in oss4 package in Ubuntu: New Status in linux-hwe-5.11 source package in Focal: New Status in oss4 source package in Focal: In Progress Bug description: [Impact] oss4 dkms will fail to build on 5.11 kernels on focal, preventing users from using those modules on more recent kernels. [Test case] Install the package and make sure it builds. [Fix] Conditionally define a function that is not used on the Linux port when LICENSED_VERSION is undefined. [Fix risk] Licensed versions will fail to build, but we don't do those. Other ports should not fail as we only patch the Linux port. [Potential regression] The dkms package may still fail to build, install or load. Or sound might not work on systems that depend on oss4. --- This is a scripted bug report about ADT failures while running oss4 tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/o/oss4/20210611_210018_1dcc5@/log.gz [Other] NB! dkms ftbfs fixes must be built in security, such that after SRU process in -proposed & -updates it can be copied into -security pocket too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-hwe-5.11/+bug/1932168/+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 1932163] Re: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
@cascardo are fixes done in ubuntu2 and ubuntu3 also needed in hirsute? If yes, can you prepare SRU for hirsute as well? If not, can you please explain why? ** Also affects: evdi (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: linux-hwe-5.11 (Ubuntu Hirsute) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932163 Title: evdi/1.7.0+dfsg-1ubuntu1~20.04.3 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in evdi package in Ubuntu: New Status in linux-hwe-5.11 package in Ubuntu: New Status in evdi source package in Focal: In Progress Status in linux-hwe-5.11 source package in Focal: New Status in evdi source package in Hirsute: New Status in linux-hwe-5.11 source package in Hirsute: New Bug description: [Impact] focal users running latest hwe kernel, version 5.11, won't be able to use evdi-dkms. [Test case] Built evdi dkms and loaded the evdi module on 5.4, 5.8 and 5.11 kernels. [Potential regression] DisplayLink devices will stop working. -- This is a scripted bug report about ADT failures while running evdi tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/e/evdi/20210611_210228_7f0da@/log.gz arm64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/e/evdi/20210612_122245_bd52e@/log.gz ppc64el: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/ppc64el/e/evdi/20210611_210028_038f3@/log.gz s390x: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/s390x/e/evdi/20210611_205902_3dc65@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evdi/+bug/1932163/+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 1932159] Re: bcmwl/6.30.223.271+bdcom-0ubuntu7~20.04.2 ADT test failure with linux-hwe-5.11/5.11.0-20.21~20.04.1
$ dput ppa:ci-train-ppa-service/4601 bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3_source.changes D: Splitting host argument out of ppa:ci-train-ppa-service/4601. D: Setting host argument. Checking signature on .changes gpg: /tmp/bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3_source.changes: Valid signature from 9B8EC849D5EF70ED Checking signature on .dsc gpg: /tmp/bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3.dsc: Valid signature from 9B8EC849D5EF70ED Uploading to ppa (via sftp to ppa.launchpad.net): Uploading bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3.dsc: done. Uploading bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3.diff.gz: done. Uploading bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3_source.buildinfo: done. Uploading bcmwl_6.30.223.271+bdcom-0ubuntu7~20.04.3_source.changes: done. Successfully uploaded packages. -- 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/1932159 Title: bcmwl/6.30.223.271+bdcom-0ubuntu7~20.04.2 ADT test failure with linux- hwe-5.11/5.11.0-20.21~20.04.1 Status in bcmwl package in Ubuntu: Fix Released Status in linux-hwe-5.11 package in Ubuntu: Invalid Status in bcmwl source package in Focal: In Progress Status in linux-hwe-5.11 source package in Focal: Invalid Bug description: This is a scripted bug report about ADT failures while running bcmwl tests for linux-hwe-5.11/5.11.0-20.21~20.04.1 on focal. Whether this is caused by the dep8 tests of the tested source or the kernel has yet to be determined. Testing failed on: amd64: https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/b/bcmwl/20210611_210047_c4a48@/log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/1932159/+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 1932582] Re: Implement support for Intel SGX
** Tags added: verification-done-hirsute ** Tags added: verification-done -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Released Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: Fix Committed Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Released Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1932582] Re: Implement support for Intel SGX
1) Booted focal VM, installed linux-azure-edge (v5.11) based kernel, which installed linux-base-sgx as a dependency from -updates $ dpkg-query -W linux-base-sgx linux-base-sgx 4.5ubuntu3.5 No SGX variables present in env 2) Enabled proposed, and installed linux-base-sgx from proposed $ dpkg-query -W linux-base-sgx linux-base-sgx 4.5ubuntu3.6 Logged in via ttyS0: ubuntu@cloudimg:~$ env | grep SGX SGX_AESM_ADDR=1 ubuntu@cloudimg:~$ systemctl --user show-environment | grep SGX SGX_AESM_ADDR=1 ubuntu@cloudimg:~$ systemctl --system show-environment | grep SGX SGX_AESM_ADDR=1 Logged in via ssh ubuntu@cloudimg:~$ ssh ubuntu@192.168.122.37 ubuntu@192.168.122.37's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.11.0-1007-azure x86_64) ... Last login: Mon Jul 5 13:38:22 2021 from 192.168.122.1 ubuntu@cloudimg:~$ env | grep SGX SGX_AESM_ADDR=1 ** Tags added: verification-done-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/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Released Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: Fix Committed Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Released Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1932582] Re: Implement support for Intel SGX
@ubuntu-sru-bot Regresssions were retried, and have now been cleared. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Released Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: Fix Committed Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Released Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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 1932582] Re: Implement support for Intel SGX
1) Booted hirsute VM, installed linux-azure (v5.11) based kernel, which installed linux-base-sgx as a dependency, and rebooted $ dpkg-query -W linux-base-sgx linux-base-sgx 4.5ubuntu5.2 rebooted and no sgx variables were present. 2) installed linux-base-sgx from proposed ubuntu@cloudimg:~$ dpkg-query -W linux-base-sgx linux-base-sgx 4.5ubuntu5.3 And rebooted Logged in via ttyS0 Last login: Mon Jul 5 14:08:10 UTC 2021 on ttyS0 ubuntu@cloudimg:~$ env | grep SGX SGX_AESM_ADDR=1 ubuntu@cloudimg:~$ systemctl --user show-environment | grep SGX SGX_AESM_ADDR=1 ubuntu@cloudimg:~$ systemctl --system show-environment | grep SGX SGX_AESM_ADDR=1 ubuntu@cloudimg:~$ ssh ubuntu@localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. ECDSA key fingerprint is SHA256:LrAhr9h2R3VjerwIMLnzTl9QmzmAvu9J47/SYyiXgIo. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts. ubuntu@localhost's password: Welcome to Ubuntu 21.04 (GNU/Linux 5.11.0-1009-azure x86_64) .. 36 updates can be applied immediately. To see these additional updates run: apt list --upgradable Last login: Mon Jul 5 14:15:34 2021 ubuntu@cloudimg:~$ env | grep SGX SGX_AESM_ADDR=1 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure-5.11 in Ubuntu. https://bugs.launchpad.net/bugs/1932582 Title: Implement support for Intel SGX Status in linux package in Ubuntu: Fix Released Status in linux-azure package in Ubuntu: Fix Released Status in linux-azure-5.11 package in Ubuntu: Invalid Status in linux-base package in Ubuntu: Fix Released Status in linux source package in Focal: Invalid Status in linux-azure source package in Focal: Invalid Status in linux-azure-5.11 source package in Focal: Fix Committed Status in linux-base source package in Focal: Fix Committed Status in linux source package in Hirsute: Fix Released Status in linux-azure source package in Hirsute: Fix Released Status in linux-azure-5.11 source package in Hirsute: Invalid Status in linux-base source package in Hirsute: Fix Committed Status in linux source package in Impish: Fix Released Status in linux-azure source package in Impish: Fix Released Status in linux-azure-5.11 source package in Impish: Invalid Status in linux-base source package in Impish: Fix Released Bug description: [Impact] Backport Linux kernel 5.11 SGX native support to new Azure Ubuntu 20.04 releases. [Fix] Update linux-base to add a UDEV rule to set group permissions on the SGX device. Add an environment variable to default to out-of-proc attestation. [Test] Install focal:linux-azure-5.11 or hirsute:linux-azure. Install linux-base-sgx reboot systemctl --user show-environment | grep SGX_AESM_ADDR systemctl --system show-environment | grep SGX_AESM_ADDR login via tty and check $ env | grep SGX_AESM_ADDR login via ssh and check $ env | grep SGX_AESM_ADDR [other info] SF:00308240 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1932582/+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
@superm1 yes I have, it is now pulled into v5.14 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c484419efc09e7234c667aa72698cb79ba8d8ed I will request it to be included in linux-stable series. Note that in Impish we have now switched to zstd compression for the initramfs, as it has even better bootspeed performance. -- 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 OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Released Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Released Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Fix Released 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. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+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 1926175] [NEW] something something precise (test bug)
Public bug reported: something something precise (test bug) ** Affects: linux-gcp (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: linux-gcp (Ubuntu Precise) Importance: Undecided Status: Won't Fix ** Affects: linux-gcp (Ubuntu Trusty) Importance: Undecided Status: In Progress ** Affects: linux-gcp (Ubuntu Xenial) Importance: Undecided Status: Invalid ** Also affects: linux-gcp (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux-gcp (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: linux-gcp (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: linux-gcp (Ubuntu) Status: New => Fix Released ** Changed in: linux-gcp (Ubuntu Xenial) Status: New => Fix Released ** Changed in: linux-gcp (Ubuntu Xenial) Status: Fix Released => Invalid ** Changed in: linux-gcp (Ubuntu Precise) Status: New => Won't Fix ** Changed in: linux-gcp (Ubuntu Trusty) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-gcp in Ubuntu. https://bugs.launchpad.net/bugs/1926175 Title: something something precise (test bug) Status in linux-gcp package in Ubuntu: Fix Released Status in linux-gcp source package in Precise: Won't Fix Status in linux-gcp source package in Trusty: In Progress Status in linux-gcp source package in Xenial: Invalid Bug description: something something precise (test bug) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-gcp/+bug/1926175/+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 1914279] Re: linux from security may force reboots without complete dkms modules
debdiffs are on https://bileto.ubuntu.com/#/ticket/4543 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1914279 Title: linux from security may force reboots without complete dkms modules Status in apt package in Ubuntu: Invalid Status in dkms package in Ubuntu: Fix Released Status in linux package in Ubuntu: Triaged Status in linux-meta package in Ubuntu: Triaged Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+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 1914279] Re: linux from security may force reboots without complete dkms modules
I've rebuilt all the packages mentioned above in bileto ppa against security pocket and pushed them to focal-proposed queue, ready for sru review and accept. All, but openafs which ftbfs now, and will need to be fixed up for v5.11 anyway. So it will be rebuild in security pocket with v5.11 fixes later. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1914279 Title: linux from security may force reboots without complete dkms modules Status in apt package in Ubuntu: Invalid Status in dkms package in Ubuntu: Fix Released Status in linux package in Ubuntu: Triaged Status in linux-meta package in Ubuntu: Triaged Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+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 1915145] Re: add modalias for testing
** Description changed: nvidia-graphics-drivers-460 [Impact] * To aid installer testing of the correct kernels with/without nvidia, it would be helpful to test nvidia driver installation in qemu VMs without actually needing nvidia hardware. * We already have `Modaliases: meta(dmi:*:pnUBUNTUQEMUTEST:*)` to test installs with oem-qemu-meta (aka certified install) * It would be useful to add nvidia modalias of `dmi:*:pvrUBUNTUNVIDIATEST:*` to nvidia-graphics-drivers-460 * This way we will be able to test generic with/without nvidia; and oem with/without nvidia. By combinding pn & pvr dmi modaliases. [Test Case] - * Setup ubuntu qemu libvirt vm with dmi sysinfo setting product version - to UBUNTUNVIDIATEST + * Setup ubuntu qemu libvirt vm with dmi sysinfo setting product version to UBUNTUNVIDIATEST + I.e. + + + UBUNTUNVIDIATEST + + + + ... + + * Boot and execute ubuntu-drivers list * Observe that nvidia drivers show up as options. [Where problems could occur] * Additional mod alias will be exposed in the package metadata, and whilst it will be installed it will not be loaded. It is purely an installer test interface. ** Patch added: "testing-modalias.patch" https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-460/+bug/1915145/+attachment/5462268/+files/testing-modalias.patch ** Changed in: nvidia-graphics-drivers-460 (Ubuntu Hirsute) Assignee: (unassigned) => Alberto Milone (albertomilone) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-460 in Ubuntu. https://bugs.launchpad.net/bugs/1915145 Title: add modalias for testing Status in nvidia-graphics-drivers-460 package in Ubuntu: New Status in nvidia-graphics-drivers-460 source package in Focal: New Status in nvidia-graphics-drivers-460 source package in Groovy: New Status in nvidia-graphics-drivers-460 source package in Hirsute: New Bug description: nvidia-graphics-drivers-460 [Impact] * To aid installer testing of the correct kernels with/without nvidia, it would be helpful to test nvidia driver installation in qemu VMs without actually needing nvidia hardware. * We already have `Modaliases: meta(dmi:*:pnUBUNTUQEMUTEST:*)` to test installs with oem-qemu-meta (aka certified install) * It would be useful to add nvidia modalias of `dmi:*:pvrUBUNTUNVIDIATEST:*` to nvidia-graphics-drivers-460 * This way we will be able to test generic with/without nvidia; and oem with/without nvidia. By combinding pn & pvr dmi modaliases. [Test Case] * Setup ubuntu qemu libvirt vm with dmi sysinfo setting product version to UBUNTUNVIDIATEST I.e. UBUNTUNVIDIATEST ... * Boot and execute ubuntu-drivers list * Observe that nvidia drivers show up as options. [Where problems could occur] * Additional mod alias will be exposed in the package metadata, and whilst it will be installed it will not be loaded. It is purely an installer test interface. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-460/+bug/1915145/+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 1920916] [NEW] sometimes cold boot hangs on unmatched board
Public bug reported: [ 16.319808] pci :04:00.0: enabling device ( -> 0002) [ 16.325596] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 [ 16.325665] L2CACHE: No. of Banks in the cache: 4 [ 16.332152] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-1002-generic #1 [ 16.332165] Call Trace: [ 16.332174] [] walk_stackframe+0x0/0xcc [ 16.336947] L2CACHE: No. of ways per bank: 16 [ 16.344054] SMP: stopping secondary CPUs [ 16.360467] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]- On cold boot, I am observing L2CACHE DirFail panic, then after soft reset it boots fine. Will try to capture the full boot log with latest kernel. ** Affects: linux-riscv (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1920916 Title: sometimes cold boot hangs on unmatched board Status in linux-riscv package in Ubuntu: New Bug description: [ 16.319808] pci :04:00.0: enabling device ( -> 0002) [ 16.325596] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 [ 16.325665] L2CACHE: No. of Banks in the cache: 4 [ 16.332152] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-1002-generic #1 [ 16.332165] Call Trace: [ 16.332174] [] walk_stackframe+0x0/0xcc [ 16.336947] L2CACHE: No. of ways per bank: 16 [ 16.344054] SMP: stopping secondary CPUs [ 16.360467] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]- On cold boot, I am observing L2CACHE DirFail panic, then after soft reset it boots fine. Will try to capture the full boot log with latest kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920916/+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 1920916] Re: cold boot panics on unmatched board, soft reboot is fine
** Summary changed: - sometimes cold boot hangs on unmatched board + cold boot panics on unmatched board, soft reboot is fine ** Attachment added: "screenlog.0" https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920916/+attachment/5480079/+files/screenlog.0 ** Description changed: - [ 16.319808] pci :04:00.0: enabling device ( -> 0002) - [ 16.325596] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 - [ 16.325665] L2CACHE: No. of Banks in the cache: 4 - [ 16.332152] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.11.0-1002-generic #1 - [ 16.332165] Call Trace: - [ 16.332174] [] walk_stackframe+0x0/0xcc - [ 16.336947] L2CACHE: No. of ways per bank: 16 - [ 16.344054] SMP: stopping secondary CPUs - [ 16.360467] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]- + [ 16.622852] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 + [ 16.629408] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-1004-generic #4-Ubuntu + [ 16.637136] Call Trace: + [ 16.639655] [] walk_stackframe+0x0/0xcc + [ 16.645131] SMP: stopping secondary CPUs + [ 16.649144] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]--- + On cold boot, I am observing L2CACHE DirFail panic, then after soft + reset it boots fine. - On cold boot, I am observing L2CACHE DirFail panic, then after soft reset it boots fine. - - Will try to capture the full boot log with latest kernel. + See full attached screenlog.0 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1920916 Title: cold boot panics on unmatched board, soft reboot is fine Status in linux-riscv package in Ubuntu: New Bug description: [ 16.622852] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 [ 16.629408] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-1004-generic #4-Ubuntu [ 16.637136] Call Trace: [ 16.639655] [] walk_stackframe+0x0/0xcc [ 16.645131] SMP: stopping secondary CPUs [ 16.649144] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]--- On cold boot, I am observing L2CACHE DirFail panic, then after soft reset it boots fine. See full attached screenlog.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920916/+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 1920916] Re: cold boot panics on unmatched board, soft reboot is fine
** Changed in: linux-riscv (Ubuntu) Milestone: None => ubuntu-21.04 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1920916 Title: cold boot panics on unmatched board, soft reboot is fine Status in linux-riscv package in Ubuntu: In Progress Bug description: [ 16.622852] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 [ 16.629408] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-1004-generic #4-Ubuntu [ 16.637136] Call Trace: [ 16.639655] [] walk_stackframe+0x0/0xcc [ 16.645131] SMP: stopping secondary CPUs [ 16.649144] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]--- On cold boot, I am observing L2CACHE DirFail panic, then after soft reset it boots fine. See full attached screenlog.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920916/+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 1918970] Re: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration
Alternative to all of the above, you could choose to "enable all the devices" hack on 18.04. Aka if the MAAS initrd includes a script to do `chzdev -e --all` by default on 18.04. -- 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/1918970 Title: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration Status in MAAS: New Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: I tried to deploy Ubuntu 18.04 with the GA-18.04 kernel on an IBM Z14 DPM Partition. The initrd fails to bring up network and thus fails to boot in MAAS. I haven't tried older versions of Ubuntu but suspect they also have the same bug. mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 chvt: can't open console No init found. Try passing init= bootarg. Couldn't get a file descriptor referring to the console /scripts/panic/console_setup: line 133: can't create /dev/tty1: No such device o r address /scripts/panic/console_setup: line 1: can't open /dev/tty1: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty2: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty2: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty3: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty3: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty4: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty4: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty5: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty5: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty6: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty6: No such device or ad dress BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) [6n [ 78.114530] random: crng init done [ 78.114538] random: 7 urandom warning(s) missed due to ratelimiting To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1918970/+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 1918970] Re: Unable to boot Ubuntu 18.04 and older on an IBM Z DPM Partition
In https://launchpad.net/ubuntu/+source/initramfs-tools/0.133ubuntu3 in eoan+ manual chzdev -e got added to activate qeth devices, if they have been specified in the ip= command, i.e. if enc300 is the device in the ip= command. This has not been backported to bionic. To boot without specifying the device name, i.e. with just mac address one will need automatic chzdev device configuration via /sys/firmware/sclp_sd/config/data that was added in s390-tools v2.5.0 fist available in cosmic+ but that also needs kernel support for sclp_sd driver to exist, i.e first added in v4.16. Thus if one wants this support one will need to backport 1) initramfs-tools changes 2) s390-tools changes 3) linux sclp_sd driver from linux-hwe to GA ** Also affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: s390-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Unable to boot Ubuntu 18.04 and older on an IBM Z DPM Partition + Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration -- 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/1918970 Title: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration Status in MAAS: New Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: I tried to deploy Ubuntu 18.04 with the GA-18.04 kernel on an IBM Z14 DPM Partition. The initrd fails to bring up network and thus fails to boot in MAAS. I haven't tried older versions of Ubuntu but suspect they also have the same bug. mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 chvt: can't open console No init found. Try passing init= bootarg. Couldn't get a file descriptor referring to the console /scripts/panic/console_setup: line 133: can't create /dev/tty1: No such device o r address /scripts/panic/console_setup: line 1: can't open /dev/tty1: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty2: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty2: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty3: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty3: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty4: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty4: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty5: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty5: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty6: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty6: No such device or ad dress BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) [6n [ 78.114530] random: crng init done [ 78.114538] random: 7 urandom warning(s) missed due to ratelimiting To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1918970/+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 1922293] Re: Snaps appear broken on 21.04 Beta with ZFS
somehow i was expecting the snap mount units to start after local- fs.target, and for zfs.target to complete by then. But it looks like that's not how things are ordered unfortunately. -- 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/1922293 Title: Snaps appear broken on 21.04 Beta with ZFS Status in snapd package in Ubuntu: Confirmed Status in zfs-linux package in Ubuntu: Confirmed Bug description: I've attempted to use two different userland snaps (qownnotes and keepassxc) neither function. When attempting to launch I get the following error: ``` chalbersma@abdos:~$ qownnotes cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_t3kehe//dev: No such file or directory ``` Additionally the snaps installed "by default" have a note of "broken" next to them : ``` chalbersma@abdos:~$ sudo snap list Name Version RevTracking Publisher Notes core18 1997 latest/stablecanonical✓ broken gnome-3-34-1804 66 latest/stable/… canonical✓ broken gtk-common-themes 1514 latest/stable/… canonical✓ broken qownnotes 21.3.9 8183 latest/stablepbek- snap-store 518latest/stable/… canonical✓ broken snapd 11402 latest/stablecanonical✓ broken ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1922293/+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 1920916] Re: cold boot panics on unmatched board, soft reboot is fine
Looks like we carry out of date l2_cache patch https://paste.ubuntu.com/p/y6hWvqYhdF/ ** Changed in: linux-riscv (Ubuntu) Status: New => In Progress ** Changed in: linux-riscv (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-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1920916 Title: cold boot panics on unmatched board, soft reboot is fine Status in linux-riscv package in Ubuntu: In Progress Bug description: [ 16.622852] Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 [ 16.629408] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-1004-generic #4-Ubuntu [ 16.637136] Call Trace: [ 16.639655] [] walk_stackframe+0x0/0xcc [ 16.645131] SMP: stopping secondary CPUs [ 16.649144] ---[ end Kernel panic - not syncing: L2CACHE: DirFail @ 0x.0001CB00 ]--- On cold boot, I am observing L2CACHE DirFail panic, then after soft reset it boots fine. See full attached screenlog.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920916/+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 1913442] Re: [Ubuntu 20.04] Problem leading IUCV service down (on s390x)
191691 has not been mirrored to launchpad, thus Ubuntu developers cannot see any of that details. Note that Ubuntu does not have access to the LTC bugzilla, instead bugproxy mirrors reports to Launchpad as needed. Please check with hws if 191691 should be mirrored across, or not. -- 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/1913442 Title: [Ubuntu 20.04] Problem leading IUCV service down (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Fix Released Status in linux source package in Focal: Incomplete Bug description: When I deployed a Ubuntu20.04 instance with kernel version of 5.4.0-58-generic under z/VM, I saw below messages from kernel and the iucvserv program malfunctioned. Hence it caused some devices like network device configuration failure and deployment failure. Dec 14 22:02:26 ub2004img iucvserv: Receive OPNCLD4 0.0.0.1 pwd sent from IUCV client. Dec 14 22:02:26 ub2004img iucvserv: /etc/iucv_authorized_userid exists, check authorization. Dec 14 22:02:26 ub2004img iucvserv: senduserid=OPNCLD4, authuserid=OPNCLD4, len=7 Dec 14 22:02:26 ub2004img iucvserv: Current version is 0.0.0.1, upgraded version is 0.0.0.1 Dec 14 22:02:26 ub2004img iucvserv: Will execute the linux command pwd 2>&1; echo iucvcmdrc=$? sent from IUCV client. Dec 14 22:02:26 ub2004img iucvserv: result length=14, send message length=14,#012 /#012iucvcmdrc=0 Dec 14 22:02:26 ub2004img kernel: [63084.184649] [ cut here ] Dec 14 22:02:26 ub2004img kernel: [63084.184654] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dma-kmalloc-1k' (offset 0, size 20)! Dec 14 22:02:26 ub2004img kernel: [63084.184680] WARNING: CPU: 1 PID: 697 at mm/usercopy.c:75 usercopy_warn+0xa0/0xd0 Dec 14 22:02:26 ub2004img kernel: [63084.184681] Modules linked in: tcp_diag udp_diag raw_diag inet_diag unix_diag xt_CT iptable_raw ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack nf_defr ag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter af_iucv nls_utf8 isofs dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua vmur vfio_ccw vfio_mdev mdev s390_trng vfio_iommu_type1 vfio sch_fq_codel drm drm _panel_orientation_quirks i2c_core ip_tables x_tables btrfs zstd_compress zlib_deflate raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear pkey zcrypt crc32_vx_s390 ghash_s390 prng aes_s390 des_s390 libdes sha3_512_s390 sha3_256_s390 sha512_s390 sha256_s390 sha1_s390 sha_common dasd_fba_mod dasd_mod qeth_l2 qeth qdio ccwgroup Dec 14 22:02:26 ub2004img kernel: [63084.184718] CPU: 1 PID: 697 Comm: iucvserv Not tainted 5.4.0-58-generic #64-Ubuntu Dec 14 22:02:26 ub2004img kernel: [63084.184718] Hardware name: IBM 8561 LT1 400 (z/VM 7.1.0) Dec 14 22:02:26 ub2004img kernel: [63084.184719] Krnl PSW : 0704c0018000 b3c37a60 (usercopy_warn+0xa0/0xd0) Dec 14 22:02:26 ub2004img kernel: [63084.184721]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Dec 14 22:02:26 ub2004img kernel: [63084.184722] Krnl GPRS: 0004 0006 0081 0007 Dec 14 22:02:26 ub2004img kernel: [63084.184722]0007 f2ecb400 b43fdc6a 03e00014 Dec 14 22:02:26 ub2004img kernel: [63084.184723] 0014 b43f01f0 Dec 14 22:02:26 ub2004img kernel: [63084.184723]aae13300 e9332a00 b3c37a5c 03e000987a10 Dec 14 22:02:26 ub2004img kernel: [63084.184728] Krnl Code: b3c37a50: c020003e310f larl%r2,b43fdc6e Dec 14 22:02:26 ub2004img kernel: [63084.184728]b3c37a56: c0e5ffedbe85 brasl %r14,b39ef760 Dec 14 22:02:26 ub2004img kernel: [63084.184728] #b3c37a5c: a7f40001 brc 15,b3c37a5e Dec 14 22:02:26 ub2004img kernel: [63084.184728] >b3c37a60: eb6ff0c4 lmg %r6,%r15,192(%r15) Dec 14 22:02:26 ub2004img kernel: [63084.184728]b3c37a66: 07fe bcr 15,%r14 Dec 14 22:02:26 ub2004img kernel: [63084.184728]b3c37a68: 47000700 bc 0,1792 Dec 14 22:02:26 ub2004img kernel: [63084.184728]b3c37a6c: c020003e30fa larl%r2,b43fdc60 Dec 14 22:02:26 ub2004img kernel: [63084.184728]b3c37a72: a7f4ffd4 brc 15,b3c37a1a Dec 14 22:02:26 ub2004img kernel: [63084.184735] Call Trace: Dec 14 22:02:26 ub2004img kernel: [63084.184736] ([] usercopy_warn+0x9c/0xd0) Dec 14 22:02:26 ub2004img kernel: [63084.184740] [ ]
[Kernel-packages] [Bug 1903288] Re: Power guest secure boot with static keys: kernel portion
Kind of wish for a config option that would do add_to_platform_keyring a built-in set of keys, until we have something like the other platforms have (ipl on s390x, uefi db on EFI platforms). Similar to how the built-in trusted keys are initialized. -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: New Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
this is all very annoying! But I see what you mean now. We probably should not add opal keys to the trusted_keyring then. I would rather avoid introducing a new CA key whilst we cannot travel to assemble and distribute CA shards offline. I'd rather somehow enable platform_keyring or IMA keyring, and make kernel have ability to specifies keys listed there at build time and ship the OPAL key there. Cause the keys we use to sign kernel image & grub-image, are not the keys that are used to signed kernel modules, hence shouldn't be in the trusted kerying. Or we can end up with a userspace .service that exports trusted_keyrings and imports them into ima keyring on everyboot. But that would be sad as well. Let me find power machines to play around with this. -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: New Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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 1903288] Re: Power guest secure boot with static keys: kernel portion
@Daniel "In either case, however, the CA that signs the kernel signing key needs to be built in to the kernel's .builtin_trusted_keys keyring." On Ubuntu, for OPAL singing, on PowerPC, we do not use CA at all. It is our understanding that firmware doesn't support verifying signature chains to a CA. Thus instead we use self-signed certificates for the kernel which have not been signed by a CA. Thus we should simply include them all in trusted keyring, and there is no need to ship anything on disk or load anything from the userspace. We have UEFI CA which is used for UEFI booting and embedded in the UEFI shim, but I do not believe it is appropriate to use that CA here, as the revocations are controlled by a KEK key which has no relationship with POWER firmware vendors. @sforshee Subject: CN = Canonical Ltd. Live Patch Signing Subject: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., OU = Secure Boot, CN = "Canonical Ltd. Secure Boot Signing (POWER, 2017)" Subject: C = GB, ST = Isle of Man, L = Douglas, O = Canonical Ltd., CN = Canonical Ltd. Kernel Module Signing This is all that's needed for now. However, we should start also shipping the next/future OPAL signing certificate that we have generated in 2019. Please add the 2019 opal signing certificate as debian/opal-2019-ppc64el.pem Key ID: 6B:E5:A1:25:FC:48:97:91:02:2C:2B:FB:54:91:16:F6:07:16:EA:81 There are no CA to add, and no keys to load from userspace. -- 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/1903288 Title: Power guest secure boot with static keys: kernel portion Status in The Ubuntu-power-systems project: Triaged Status in linux package in Ubuntu: New Bug description: == Comment: #2 - Daniel John Axtens - 2020-11-05 20:15:10 == This is the kernel side of changes needed for LPAR/guest secure boot. Because Ubuntu keeps its kernels so wonderfully up to date, I don't think there are any extra patches you need to pick up. (I'll double- check against the 21.04 tree once my git pulls finish!) However, we potentially need some configuration changes to make sure kexec-ing into a crashdump kernel still works. Because Lockdown requires that kexec kernels are signed by a key trusted by IMA, the public key for used for signing the kdump kernel needs to be in the IMA keyring or the platform keyring. For host secure boot (and in the UEFI case), it's loaded into the platform keyring. But in the case of guest secure boot with static keys, it's not loaded into the platform keyring so it needs to be loaded into the IMA keyring. This is easy enough to do. Firstly, load the Secure Boot CA into the .primary_trusted_keys keyring via the CONFIG_SYSTEM_TRUSTED_KEYS property. We assume the key used to sign the kernel is signed by this CA. Then, enable IMA_LOAD_X509, which allows certificates signed by a key on the .primary_trusted_keys keyring to be loaded into the IMA keyring. Then set IMA_X509_PATH to provide a path to the signing key on installed file system. (It may also be possible to do this step in userspace, so long as the CA is trusted by the kernel.) Then that key will be loaded into the .ima keyring at boot and be used to appraise the kexec kernel for crashdumps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+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
@Fred eldmannen+launchpad This issue is only fixed in the Ubuntu patchset for the Linux Kernel. Although I have submitted this fix upstream, it has not been picked up yet by kernel.org vanilla kernels. See https://lkml.org/lkml/2021/1/14/1091 The mainline builds you point to, do not contain Ubuntu patchset, and thus are as vanilla as possible. Meaning that yes, those builds are affected by this issue. There should be point release updates for Hirsute soon. -- 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 OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Released Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Released Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Fix Released 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. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+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 1920774] [NEW] v5.11 kernel seems to sometimes hang on unmatched board
Public bug reported: v5.11 kernel seems to sometimes hang on unmatched board ** Affects: linux-riscv (Ubuntu) Importance: Undecided Status: New ** Summary changed: - v5.11 kernel seems to hang on unmatched board + v5.11 kernel seems to sometimes hang on unmatched board ** Description changed: - v5.11 kernel seems to hang on unmatched board + v5.11 kernel seems to sometimes hang on unmatched board -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1920774 Title: v5.11 kernel seems to sometimes hang on unmatched board Status in linux-riscv package in Ubuntu: New Bug description: v5.11 kernel seems to sometimes hang on unmatched board To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920774/+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 1920774] Re: v5.11 kernel seems to sometimes hang on unmatched board
For debugging i think it is best to use something like: console=ttySIF0,115200 earlycon=sbi note that by default kernel/systemd seem to enable sbi0 hvc0 (via sbi) ttySIF0 consoles all of which seem to be the same thing. It is quite confusing. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1920774 Title: v5.11 kernel seems to sometimes hang on unmatched board Status in linux-riscv package in Ubuntu: New Bug description: v5.11 kernel seems to sometimes hang on unmatched board To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1920774/+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 1912752] Re: linux-uc20-efi: megaraid_sas required in the initrd
** Also affects: ubuntu-core-initramfs Importance: Undecided Status: New ** Changed in: ubuntu-core-initramfs 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/1912752 Title: linux-uc20-efi: megaraid_sas required in the initrd Status in HWE Next: New Status in ubuntu-core-initramfs: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Bug description: == Impact == Dell R340 fails to boot with UC20 pc-kernel snap because of unable to find the storage device. == Fix == In this case, storage disks are connected through a controller enabled by kernel module megaraid_sas, hence the module must be presented in the initrd in order to make the system boot. == Risk of Regression == Low. We're only adding an existing module into the initrd. The only downside may be the small increase of the snap size. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1912752/+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 1914279] Re: linux from security may force reboots without complete dkms modules
@kernel team please check which dkms packages in -updates fix FTBFS, and if they need to be rebuilt in -security pocket and released in -security pocket. ** Changed in: linux-meta (Ubuntu) Status: New => Triaged ** Changed in: linux (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to dkms in Ubuntu. https://bugs.launchpad.net/bugs/1914279 Title: linux from security may force reboots without complete dkms modules Status in apt package in Ubuntu: Invalid Status in dkms package in Ubuntu: New Status in linux package in Ubuntu: Triaged Status in linux-meta package in Ubuntu: Triaged Status in unattended-upgrades package in Ubuntu: Invalid Status in update-manager package in Ubuntu: Invalid Bug description: Whilst discussing https://discourse.ubuntu.com/t/improvements-for-hardware-support-in- ubuntu-desktop-installation-media/20606 We have noticed a reference to somebody not having working backport- iwlwifi-dkms, whilst SRU of that happened before the v5.4 -> v5.8 switch. However, kernel meta switch was pushed to security pocket, but the dkms modules are all in -updates only. This may result in people automatically installing the new kernel with unatanded upgrades; dkms modules failing to build; and a reboot required flag left on disk. At this point launching update manager will not offer to install dkms modules from updates, and will guide the users to reboot. which will then cause them to boot the new kernel without the dkms modules that might be providing networking for them. Should dkms modules SRUs always getting published into -security pocket, as well as the -updates pocket? Should linux maintainer scripts prevent touching reboot required flag if any dkms modules fail to build? Should apt / unattanded-upgrades / update-manager always update dkms modules with kernels? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+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 1916971] Re: After fresh Ubuntu 20.04 install, downgrading Nvidia driver doesn't update nvidia modules in kernel
Can you please provide the output of: $ sudo ubuntu-drivers list In the live session? There are two ways to get the nvidia kernel driver. One option is to compile it from scratch on the users machine with dkms. THe other option is to install a metapackage linux-modules-nvidia for the appropriate kernel flavour and the appropriate nvidia revsision which provides a prebuild, not linked, and secureboot signed nvidia module. So as to why the dkms one will not work or load on secureboot machines, unless one goes through cryptic MOK key enrollment procedure during boot. The secureboot signed nvidia module works on secureboot machines without any additional steps by the user. But the caveat is that the secureboot signed ones must be kept in correct tandem with the kernel flavour & nvidia revisions. Anything you install from the PPA will not be secureboot signed, and thus need MOK signing. ** Also affects: nvidia-graphics-drivers-460 (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to nvidia-graphics-drivers-460 in Ubuntu. https://bugs.launchpad.net/bugs/1916971 Title: After fresh Ubuntu 20.04 install, downgrading Nvidia driver doesn't update nvidia modules in kernel Status in nvidia-graphics-drivers-460 package in Ubuntu: New Status in ubiquity package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Bug description: SYSTEM: Laptop: ASUS ROG GL552VW OS: Ubuntu 20.04.2 LTS GRAPHICS: Nvidia Geforce GTX 960m AND Intel HD Graphics Linux kernel version: 5.8.0-44-generic SUMMARY: From a fresh working install of Ubuntu 20.04, I downgraded from nvidia-driver-460 by installing nvidia-driver-440 (which actually is a transitional package to nvidia-driver-450 but I didn't know this). After reboot I couldn't reach login-screen and instead got a black screen. Problem was that sudo apt-get install nvidia-driver-440 did not insert nvidia modules v450 in kernel since never versions v460 were found. This was solved by uninstalling linux-modules-nvidia-460 packages and instead installing linux-modules-nvidia-450 packages (see WORKAROUND below for instructions). STEPS TO REPRODUCE: Install Ubuntu 20.04. During installation, allow for the installation of proprietary drivers. Once Ubuntu 20.04 has started, open a terminal and run the following: sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt-get update sudo apt-get install nvidia-driver-440 sudo shutdown reboot now PROBLEM: After reboot, you can't reach login screen. Instead you get stuck during bootup. WORKAROUND: WARNING: BETTER WORKAROUND PROBABLY EXISTS! DON'T JUST COPY-PASTE INSTRUCTIONS. PAY ATTENTION TO WHAT NVIDIA DRVER AND LINUX KERNEL VERSIONS ARE RELEVANT FOR YOU! Run dpkg --list | grep linux-image to see what linux kenrel versions you have installed. Remove the linux-modules-nvidia-460 packages and install the corresponding linux-modules-nvidia-450 packages. In my case I had Linux kernel versions 5.8.0-44-generic and 5.8.0-43-generic installed so I did as follows from recovery mode with network (instead of entering recovery mode, you should be able to press CTRL+ALT+F1 from the blank screen after bootup, login with username and password and then running these commands): sudo apt-get autoremove --purge linux-modules-nvidia-460-5.8.0-44-generic linux-modules-nvidia-460-5.8.0-43-generic sudo apt-get install linux-modules-nvidia-450-5.8.0-44-generic linux-modules-nvidia-450-5.8.0-43-generic sudo shutdown reboot now QUESTION: Why was the linux-modules-nvidia-460 packages installed by the Ubuntu installer to begin with? I ask since I later removed the linux- modules-nvidia-450 packages (OBSERVE: 450, not 460) and used the Additional Drivers GUI to update back to nvidia-driver-460. Now linux- modules-nvidia-460 packages are NOT installed but the following still outputs 460: modinfo nvidia | grep -i version LOG: This is a relevant part of /var/log/apt/term.log for when I installed nvidia-driver-440 nvidia.ko: Running module version sanity check. Error! Module version 450.102.04 for nvidia.ko is not newer than what is already found in kernel 5.8.0-44-generic (460.39). You may override by specifying --force. nvidia-modeset.ko: Running module version sanity check. Error! Module version 450.102.04 for nvidia-modeset.ko is not newer than what is already found in kernel 5.8.0-44-generic (460.39). You may override by specifying --force. nvidia-drm.ko: Running module version sanity check. Error! Module version 450.102.04 for nvidia-drm.ko is not newer than what is already found in kernel 5.8.0-44-generic (460.39). You may override by specifying --force. nvidia-uvm.ko:
[Kernel-packages] [Bug 1912752] Re: linux-uc20-efi: megaraid_sas required in the initrd
ubuntu-core-initramfs v40 has support for main & server features, which on x86 are enabled by default. The next snap build of pc-kernel in 20/ tracks should contain the required modules. ** Changed in: ubuntu-core-initramfs 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/1912752 Title: linux-uc20-efi: megaraid_sas required in the initrd Status in HWE Next: New Status in ubuntu-core-initramfs: Fix Released Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Bug description: == Impact == Dell R340 fails to boot with UC20 pc-kernel snap because of unable to find the storage device. == Fix == In this case, storage disks are connected through a controller enabled by kernel module megaraid_sas, hence the module must be presented in the initrd in order to make the system boot. == Risk of Regression == Low. We're only adding an existing module into the initrd. The only downside may be the small increase of the snap size. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1912752/+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 1912752] Re: linux-uc20-efi: megaraid_sas required in the initrd
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1916165 -- 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/1912752 Title: linux-uc20-efi: megaraid_sas required in the initrd Status in HWE Next: New Status in ubuntu-core-initramfs: Fix Released Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Bug description: == Impact == Dell R340 fails to boot with UC20 pc-kernel snap because of unable to find the storage device. == Fix == In this case, storage disks are connected through a controller enabled by kernel module megaraid_sas, hence the module must be presented in the initrd in order to make the system boot. == Risk of Regression == Low. We're only adding an existing module into the initrd. The only downside may be the small increase of the snap size. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/1912752/+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 1923084] [NEW] duplicate consoles on riscv64
Public bug reported: When booting on SiFive boards, there are two gettys launched on the same console. There is sifive serial console which is the active/only physical console. But also, there is serial console exposed over legacy opensbi extension; which in linux kernel is implemented as hvc0 console, which systemd starts getty for. The issue is that the both consoles are actually the same one. Thus some other distros chose to hard-code disable hvc0 console on riscv64. But given that the legacy sbi serial console extension will eventually go away, it makes sense to disable that in the kernel out right. By setting: +# CONFIG_RISCV_SBI_V01 is not set +# CONFIG_SERIAL_EARLYCON_RISCV_SBI is not set +# CONFIG_HVC_RISCV_SBI is not set This way sifive0 console will be discovered and used automatically; ditto earlyprintk without needing to specify sbi or explicitely set sifive0 console. This will also improve UX experience with just a single getty on the serial connection. ** Affects: linux-riscv (Ubuntu) Importance: Critical Status: Confirmed ** Changed in: linux-riscv (Ubuntu) Milestone: None => ubuntu-21.04 ** Changed in: linux-riscv (Ubuntu) Importance: Undecided => Critical ** Changed in: linux-riscv (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1923084 Title: duplicate consoles on riscv64 Status in linux-riscv package in Ubuntu: Confirmed Bug description: When booting on SiFive boards, there are two gettys launched on the same console. There is sifive serial console which is the active/only physical console. But also, there is serial console exposed over legacy opensbi extension; which in linux kernel is implemented as hvc0 console, which systemd starts getty for. The issue is that the both consoles are actually the same one. Thus some other distros chose to hard-code disable hvc0 console on riscv64. But given that the legacy sbi serial console extension will eventually go away, it makes sense to disable that in the kernel out right. By setting: +# CONFIG_RISCV_SBI_V01 is not set +# CONFIG_SERIAL_EARLYCON_RISCV_SBI is not set +# CONFIG_HVC_RISCV_SBI is not set This way sifive0 console will be discovered and used automatically; ditto earlyprintk without needing to specify sbi or explicitely set sifive0 console. This will also improve UX experience with just a single getty on the serial connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1923084/+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 1923084] Re: duplicate consoles on riscv64
** Description changed: When booting on SiFive boards, there are two gettys launched on the same console. There is sifive serial console which is the active/only physical console. But also, there is serial console exposed over legacy opensbi extension; which in linux kernel is implemented as hvc0 console, which systemd starts getty for. The issue is that the both consoles are actually the same one. Thus some other distros chose to hard-code disable hvc0 console on riscv64. But given that the legacy sbi serial console extension will eventually go away, it makes sense to disable that in the kernel out right. By setting: +# CONFIG_RISCV_SBI_V01 is not set +# CONFIG_SERIAL_EARLYCON_RISCV_SBI is not set +# CONFIG_HVC_RISCV_SBI is not set This way sifive0 console will be discovered and used automatically; ditto earlyprintk without needing to specify sbi or explicitely set sifive0 console. This will also improve UX experience with just a single getty on the serial connection. + + Before the patch is applied: + # ls /run/systemd/generator/getty.target.wants/ + serial-getty@hvc0.service serial-getty@ttySIF0.service + + After the patch is applied: + $ sudo ls /run/systemd/generator/getty.target.wants/ + serial-getty@ttySIF0.service -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1923084 Title: duplicate consoles on riscv64 Status in linux-riscv package in Ubuntu: Confirmed Bug description: When booting on SiFive boards, there are two gettys launched on the same console. There is sifive serial console which is the active/only physical console. But also, there is serial console exposed over legacy opensbi extension; which in linux kernel is implemented as hvc0 console, which systemd starts getty for. The issue is that the both consoles are actually the same one. Thus some other distros chose to hard-code disable hvc0 console on riscv64. But given that the legacy sbi serial console extension will eventually go away, it makes sense to disable that in the kernel out right. By setting: +# CONFIG_RISCV_SBI_V01 is not set +# CONFIG_SERIAL_EARLYCON_RISCV_SBI is not set +# CONFIG_HVC_RISCV_SBI is not set This way sifive0 console will be discovered and used automatically; ditto earlyprintk without needing to specify sbi or explicitely set sifive0 console. This will also improve UX experience with just a single getty on the serial connection. Before the patch is applied: # ls /run/systemd/generator/getty.target.wants/ serial-getty@hvc0.service serial-getty@ttySIF0.service After the patch is applied: $ sudo ls /run/systemd/generator/getty.target.wants/ serial-getty@ttySIF0.service To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1923084/+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 1923162] Re: riscv64 images fail to boot in qemu
** Also affects: linux-riscv (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-riscv in Ubuntu. https://bugs.launchpad.net/bugs/1923162 Title: riscv64 images fail to boot in qemu Status in linux-riscv package in Ubuntu: New Status in u-boot package in Ubuntu: New Bug description: When booting v5.11 based riscv unmatched image in qemu with uboot, it fails to boot. When booting v5.11 based riscv unmatched kernel+initrd directly, it boots fine. Somehow, it seems that u-boot fails to correctly load & start v5.11 kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1923162/+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
