[Bug 1905156] Re: netplan KeyError with gretap in bridge
** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905156 Title: netplan KeyError with gretap in bridge To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1905156/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1904549] Re: MTU is not set on vlan interface
I wonder if you need more mtu settings on: * ens10f2 * ens10f3 * bond-manlan I don't think that MTU is allowed to be higher on a vlan, than on bond- man, than on physical interfaces. Why did you not set mtu: 9000 on bond- manlan? however that does not explain how come the vlans on top of bond-core / bond-oam are not 9000. ** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1904549 Title: MTU is not set on vlan interface To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1904549/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1904549] Re: MTU is not set on vlan interface
this could be udevd/networkd bug which both fiddle with mtu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1904549 Title: MTU is not set on vlan interface To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1904549/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905274] [NEW] enable u-boot spl for riscv64
Public bug reported: enable u-boot spl for riscv64 1) build with opensbi specified 2) ship uboot-spl for unleashed ** Affects: u-boot (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905274 Title: enable u-boot spl for riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/1905274/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905274] Re: enable u-boot spl for riscv64
** Also affects: livecd-rootfs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905274 Title: enable u-boot spl for riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1905274/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905274] Re: enable u-boot spl for riscv64
** Description changed: enable u-boot spl for riscv64 - 1) build with opensbi specified - 2) ship uboot-spl for unleashed + 1) backport opensbi 0.8 to focal + 2) build u-boot with opensbi specified + 3) ship uboot-spl in the cloud image -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905274 Title: enable u-boot spl for riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1905274/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905274] Re: enable u-boot spl for riscv64
Probs https://github.com/canonical/cloud-init/pull/687/files is wanted too. ** Also affects: opensbi (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905274 Title: enable u-boot spl for riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1905274/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905456] [NEW] OpenSBI 0.8 backport
Public bug reported: OpenSBI 0.8 backport [Impact] * OpenSBI is used to create RISC-V images for various boards and to boot RISC-V virtual machines. * 0.7 & 0.8 add support for more hardware, but are otherwise backwards compatible. * qemu/virt file location got moved to generic, add backwards compatible symlink for it, to avoid breaking any stable users. [Test Case] * Boot cpc hirsute cloud image using opensbi fw loader from qemu/virt and generic location [Where problems could occur] * OpenSBI adds more hardware features, which some kernels might not be compatible with. Given how quickly the platform evolves newer OpenSBI is better. [Other Info] OpenSBI Version 0.8 @avpatel avpatel released this on 20 Jun This release has: Simple FDT timer driver framework Simple FDT ipi driver framework Simple FDT irqchip driver framework Simple FDT serial framework Generic FDT based platform support Nuclei UX600 platform support Detect HART CSRs at boot time Multi-PLIC support Multi-CLINT support Allow multiple builtin DTBs Hypervisor v0.6.1 specification support Shakti C-class platform support OpenSBI Version 0.7 @avpatel avpatel released this on 20 Apr This release has: Lots of code cleanups Lots of performance improvements SBI v0.2 HSM extension Simple bitops library Simple bitmap library Simple hartmask library Sparse and discontinuous HART id support Memory reservation in DTB passed to next booting stage OpenPiton platform support ** Affects: opensbi (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905456 Title: OpenSBI 0.8 backport To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1905456/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905456] Re: OpenSBI 0.8 backport
** Also affects: opensbi (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: opensbi (Ubuntu) Status: New => Won't Fix ** Changed in: opensbi (Ubuntu) Status: Won't Fix => Fix Released ** Changed in: opensbi (Ubuntu Focal) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905456 Title: OpenSBI 0.8 backport To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1905456/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905456] Re: OpenSBI 0.8 backport
** Changed in: opensbi (Ubuntu Focal) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905456 Title: OpenSBI 0.8 backport To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1905456/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905412] Re: LVM install broken if other disks have meta-data on the VG name already
One can make these things unambiguous. curtin could generate a uuid on the fly, and then pass vg_uuid to all the commands it uses. or we could start making slightly more unique vg names, i.e. ubuntu-vg- 3a185. I'm not sure what's best. Indeed this is a long standing issue we have been observing with d-i, ubiquity, curtin, subiquity =) Even mounting backup of one Ubuntu system, on another leads to similar confusions. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905412 Title: LVM install broken if other disks have meta-data on the VG name already To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1905412/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905456] Re: OpenSBI 0.8 backport
** Description changed: OpenSBI 0.8 backport [Impact] - * OpenSBI is used to create RISC-V images for various boards and to + * OpenSBI is used to create RISC-V images for various boards and to boot RISC-V virtual machines. - * 0.7 & 0.8 add support for more hardware, but are otherwise backwards + * 0.7 & 0.8 add support for more hardware, but are otherwise backwards compatible. - * qemu/virt file location got moved to generic, add backwards + * qemu/virt file location got moved to generic, add backwards compatible symlink for it, to avoid breaking any stable users. [Test Case] - * Boot cpc hirsute cloud image using opensbi fw loader from qemu/virt + * Boot cpc hirsute cloud image using opensbi fw loader from qemu/virt and generic location [Where problems could occur] - * OpenSBI adds more hardware features, which some kernels might not be + * OpenSBI adds more hardware features, which some kernels might not be compatible with. Given how quickly the platform evolves newer OpenSBI is - better. + better. But things may fail to boot, or missbehave - i.e. a VM that used + to boot and not work, will now boot and not work differently =) for + example there are shutdown/poweroff/reboot issues with any sets of + opensbi & Ubuntu kernels. [Other Info] - + OpenSBI Version 0.8 @avpatel avpatel released this on 20 Jun This release has: Simple FDT timer driver framework Simple FDT ipi driver framework Simple FDT irqchip driver framework Simple FDT serial framework Generic FDT based platform support Nuclei UX600 platform support Detect HART CSRs at boot time Multi-PLIC support Multi-CLINT support Allow multiple builtin DTBs Hypervisor v0.6.1 specification support Shakti C-class platform support OpenSBI Version 0.7 @avpatel avpatel released this on 20 Apr This release has: Lots of code cleanups Lots of performance improvements SBI v0.2 HSM extension Simple bitops library Simple bitmap library Simple hartmask library Sparse and discontinuous HART id support Memory reservation in DTB passed to next booting stage OpenPiton platform support -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905456 Title: OpenSBI 0.8 backport To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1905456/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905274] Re: enable u-boot spl for riscv64
** No longer affects: opensbi (Ubuntu) ** Description changed: enable u-boot spl for riscv64 1) backport opensbi 0.8 to focal + https://bugs.launchpad.net/ubuntu/focal/+source/opensbi/+bug/1905456 + 2) build u-boot with opensbi specified + 3) ship uboot-spl in the cloud image -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905274 Title: enable u-boot spl for riscv64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1905274/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905491] Re: Recent (Nov 2020) ISO copied to USB Drive cannot load
@vorlon "Startup Disk Creator" is the name in the desktop.file of the usb-creator that we do ship in the archive, and I think we created... However, I do wish people would use "GNOME Disks" to restore .iso on usb stick =/ ** Also affects: usb-creator (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905491 Title: Recent (Nov 2020) ISO copied to USB Drive cannot load To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1905491/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
So lz4 compressed initrd looks like this with hexdump 568f580 0523 00ac 54bf 4152 4c49 5245 2121 0021 568f590 0001 1cff 0050 568f59a I do wonder what ram is initialized too, and how those things look when kernel reads initrd from memory as loaded by the bootloader / qemu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905620] [NEW] please promote modules from extra to modules for HiFive Unleashed
Public bug reported: please promote modules from extra to modules for HiFive Unleashed The following modules are used by the HiFive Unleashed board from extra Please install them in modules. linux-modules-extra-5.4.0-24-generic: /lib/modules/5.4.0-24-generic/kernel/drivers/net/phy/mscc.ko linux-modules-extra-5.4.0-24-generic: /lib/modules/5.4.0-24-generic/kernel/drivers/net/ethernet/cadence/macb.ko linux-modules-extra-5.4.0-24-generic: /lib/modules/5.4.0-24-generic/kernel/drivers/i2c/busses/i2c-ocores.ko ** Affects: linux-riscv (Ubuntu) Importance: High Status: Triaged ** Tags: riscv64 ** Tags added: riscv64 ** Changed in: linux-riscv (Ubuntu) Status: New => Triaged ** Changed in: linux-riscv (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905620 Title: please promote modules from extra to modules for HiFive Unleashed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1905620/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
** Also affects: grub2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
NAK on the linux patch. I think this is a grub bug. When loading multiple initrds, grub aligns_up each one of them at 4bytes boundary, and allocates pages for that. And it declares and passes ramdisk_image as the total allocated memory. Rather than the true size of the initrds. ** Changed in: grub2 (Ubuntu) Status: New => Triaged ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
As discussed at https://github.com/lz4/lz4/issues/956 I really think it is grub2 secureboot patches linuxefi bug. WIP thing is here https://github.com/rhboot/grub2/pull/77/files ** Bug watch added: github.com/lz4/lz4/issues #956 https://github.com/lz4/lz4/issues/956 ** Changed in: grub2 (Ubuntu) Assignee: (unassigned) => Dimitri John Ledkov (xnox) ** Changed in: grub2 (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905807] [NEW] insecure W+X mapping
Public bug reported: [ 19.051518] Freeing unused kernel memory: 308K [ 19.062326] [ cut here ] [ 19.066219] riscv/mm: Found insecure W+X mapping at address (ptrval)/0xffdff800 [ 19.074930] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/ptdump.c:200 note_page+0x24c/0x252 [ 19.082806] Modules linked in: [ 19.085825] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-10-generic #12+21.04.1-Ubuntu [ 19.094007] epc: ffe000208f18 ra : ffe000208f18 sp : ffe1f5b9fb30 [ 19.101104] gp : ffe001728ee0 tp : ffe1f5bedc00 t0 : ffe00173edf8 [ 19.108330] t1 : ffe00173ed90 t2 : 0001feca5000 s0 : ffe1f5b9fb80 [ 19.115536] s1 : ffe1f5b9fe10 a0 : 0053 a1 : 00020020 [ 19.122743] a2 : ffe1f5b9f870 a3 : a4 : ffe0016200f8 [ 19.129949] a5 : ffe0016200f8 a6 : 00c1 a7 : ffe0006f27fe [ 19.137156] s2 : ffdff8001000 s3 : s4 : 0004 [ 19.144376] s5 : s6 : s7 : ffe1f5b9fd20 [ 19.151570] s8 : ffdff8001000 s9 : ffe00172a148 s10: ffdff8002000 [ 19.158775] s11: ffe000c16e20 t3 : 0003ce50 t4 : 0003ce50 [ 19.165980] t5 : t6 : ffe001739462 [ 19.171255] status: 00020120 badaddr: cause: 0003 [ 19.179177] ---[ end trace 72fa85d58b123e2f ]--- [ 19.184544] Checked W+X mappings: failed, 513 W+X pages found [ 19.189561] Run /init as init process Not sure what that means. This is on [0.00] Linux version 5.8.0-10-generic (buildd@riscv64-qemu-lcy01-087) (gcc (Ubuntu 10.2.0-18ubuntu1) 10.2.0, GNU ld (GNU Binutils for Ubuntu) 2.35.1) #12+21.04.1-Ubuntu SMP Fri Nov 20 16:26:05 UTC 2020 (Ubuntu 5.8.0-10.12+21.04.1-generic 5.8.17) will try to get full logs. ** Affects: linux-riscv (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905807 Title: insecure W+X mapping To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-riscv/+bug/1905807/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
@twetzel21 this is not related to those changes at all. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906320] [NEW] fake-device-wrapper should bind-mount efivars
Public bug reported: /usr/share/ubuntu-drivers-common/fake-devices-wrapper should bindmount efivars under testbed.get_root_dir(). Ie. such that /sys/firmware/efi/efivars is correctly available under the umockdev test-bed. That way when testing subiquity, it should correctly observe if it was booted under secureboot, or not. Or maybe we can create a few options to fake-devices-wrapper whether or not to present Secureboot. ** Affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1906320 Title: fake-device-wrapper should bind-mount efivars To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1906320/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
** Changed in: grub2 (Ubuntu) Status: Triaged => Invalid ** Changed in: linux (Ubuntu) Status: Invalid => Triaged -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
so what grub is doing is correct. It pads/aligns every initrd by 4, which is fine, and as per spec. https://www.kernel.org/doc/html/latest/driver-api/early-userspace /buffer-format.html initramfs size can be filled with arbitrary amount of "\0" all the way upto initramfs_size. "In human terms, the initramfs buffer contains a collection of compressed and/or uncompressed cpio archives (in the “newc” or “crc” formats); arbitrary amounts zero bytes (for padding) can be added between members." Thus it feels to me that decompress_unlz4.c method in the kernel does not correctly stop decompressing and returning consumed output position (posp). For example, decompress_inflate.c skips over trailer and updates output pos by 8, at the end of successful conversion. Similarly unlzma also updates posp at the end of conversion. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1865032] Re: [UBUNTU] zipl/libc: Fix potential buffer overflow in printf
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1865032 Title: [UBUNTU] zipl/libc: Fix potential buffer overflow in printf To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1865032/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892369] Re: Impossible to skip integrity test for ubuntu-server 20.04.1 iso
You can boot with a cmdline option to skip that. http://manpages.ubuntu.com/manpages/hirsute/en/man7/casper.7.html#recognized%20boot%20options fsck.mode=skip Let you skip the file system check on boot. Can you ellaborate a bit more, and make sure that the console you are observing is the one connected to the grub/initrd? Is this a serial console, tty1, hvc0 or something else? ** Also affects: casper (Ubuntu) Importance: Undecided Status: New ** Changed in: ubiquity (Ubuntu) Status: Confirmed => Invalid ** Also affects: subiquity Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892369 Title: Impossible to skip integrity test for ubuntu-server 20.04.1 iso To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1892369/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892369] Re: Impossible to skip integrity test for ubuntu-server 20.04.1 iso
live-server bugs go against subiquity project, rather than ubiquity. and casper is the thing that does the integrity check. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892369 Title: Impossible to skip integrity test for ubuntu-server 20.04.1 iso To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1892369/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892369] Re: Impossible to skip integrity test for ubuntu-server 20.04.1 iso
separately remote iso mounting may be slow, thus you should try netbooting instead. one can copy the kernel & initrd out of the iso. Boot them, with cmdline: ip=dhcp url=http://hostname/url/to/matching-full.iso That way, initrd will establish networking and will download iso into ram, validate it very quickly, and boot. This usually yields faster install times. If your target machine has enough RAM, something like more than 4GB. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892369 Title: Impossible to skip integrity test for ubuntu-server 20.04.1 iso To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1892369/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835660] Re: initramfs unpacking failed
** Description changed: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. + + [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. ** Patch added: "0001-lib-decompress_unlz4.c-correctly-handle-zero-padding.patch" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660/+attachment/5440421/+files/0001-lib-decompress_unlz4.c-correctly-handle-zero-padding.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child
** Also affects: ca-certificates (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child
This does raise a question as to why we don't provide a system nssdb. I think we should. I wonder if libnss or libnss3-tools could ship ca- certificates hook to provide a system nssdb certificate store. If we are changing backends, and certs were provided for the nss backend, imho we should automatically convert them and keep them active for the openssl backend. However unlikely it is that somebody made nss- based p11_child work. In nss, we do set minimum TLS version TLSv1.2 but we do not enforce 112 bits of security like we do with OpenSSL. Specifically that is 2k RSA minimum key size, nor prohibit SHA1/MD5 cert hashes, and any cipher suites that use RC4. These changes in minimum requirements do not affect p11_child, but would affect sssd itself when talking over ldaps. I would be worried that an LDAP server has a lowish sized key in their cert, and suddenly an upgrade of sssd, once caches expire, prevent logins. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child
If we want to change the main sssd backend from nss to openssl, imho it would be prudent enough to use http://manpages.ubuntu.com/manpages/hirsute/en/man3/SSL_set_security_level.3ssl.html APIs to set_security_level to 1. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child
Actually, I don't see sssd at all using TLS connections, does it? It seems that to perform ldaps connections, it uses libldap from openldap which in turn uses GnuTLS. And any and all TLS LDAPS options are simply passed through to the libldap. Inspecting all sssd binary packages I can see that only p11_child is the only one using libssl and that does not do TLS. libsss-certmap0 uses libcrypto.so.1.1 only for certificate parsing but not for TLS. Thus changing nss => openssl backend should be immaterial to what sssd uses from them. The only concern from me is to migrate custom certs that p11_child trusts, if there are any configured, and migration is needed between the backends. I don't know how to configure p11_child but I do have smartcard reader and multiple smartcards so happy to test things =) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1905790 Title: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1905790/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906668] [NEW] [MIR] opensbi
Public bug reported: Availability: in universe Rationale: opensbi is a bootloader/firmware component for riscv64. It is used by qemu-system-riscv64 to load uboot-qemu firmware which then can load kernel/initrd of a cloud-image to boot it. It is also used as a build-dependency by u-boot, to create combined uboot-spl (secondary program loader) image. Such a combind image of opensbi+uboot+dtb can be used to create selfcontained bootable firmware on an sd-card, to allow booting SiFive HiFive Boards. Quality assurance: The package simply provides a static datafile. It's upto qemu & u-boot to consume it, which they do. The paths and features it provides are fairly well defined with SBI specifications with uboot and kernel adhere to. Dependencies: It is effectively freestanding ELF object without dependencies. Hence it is packaged as arch:all package. Standards compliance: Packages files in multiarch locations for the supported platforms. Maintenance: In sync with Debian, to be maintained by Foundations, foundations-bugs subscribed. Background information: Example usage with cloud-image is documented at https://wiki.ubuntu.com/RISC-V How it is used by u-boot can be seen in this diff http://launchpadlibrarian.net/508302547/u-boot_2020.10+dfsg- 1ubuntu2_2020.10+dfsg-1ubuntu3.diff.gz Security checks https://github.com/riscv/opensbi/security/advisories There aren't any published security advisories at the moment. The code however runs in M-mode to interface with S-mode & HS-modes, thus this is highly privileged code used as firmware. No executables or shared libraries or daemons shipped. Does not open ports. ** Affects: opensbi (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: hirsute ** Changed in: opensbi (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1906668 Title: [MIR] opensbi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/opensbi/+bug/1906668/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906671] [NEW] [MIR] usrmerge
Public bug reported: [Availability] In universe. [Rationale] Since Disco, Ubuntu has defaulted to merged usr systems, specifically that /lib is a symlink to /usr/lib. However, we have not yet completed this transition for systems that were installed pre-disco. This package performs such transition using maintainer scripts. It has been tested and improved thoroughly and has managed to work with all sorts of packages that happened to be installed on the system. For systems that were installed post disco, this package is effectively a no-op. Systems that use nfs mounting with split /usr care must be taken to ensure that initrd mounts nfs-backed /usr. The package aborts configuration if such rare configuration is detected to avoid potentially bracking reboot. For all other systems, we always provide a fallback initrd which has been mounting both / and /usr whenever possible. [Security] The package ships two perl scripts, which are executed by root from maintainer scripts. [Quality assurance] There is debconf question one can preseed to prevent the migration, there is README.Debian explaining what it does and how. It is a one-way / one-time migration, removing the package will not undo the migration. [Dependencies] Perl, and many documented conflicts to ensure that usrmerge compatible packages are on disk prior to migration. [Standards compliance] Adheres to Debian Policy. [Maintenance] Maintained in Debian, merged and supported by Foundations, foundations- bugs is subscribed. [Background information] This will complete usrmerge migration, and will allow to switch buildds to build packages with merged-usr by default. ** Affects: usrmerge (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: hirsute ** Changed in: usrmerge (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1906671 Title: [MIR] usrmerge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/usrmerge/+bug/1906671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914279 Title: linux from security may force reboots without complete dkms modules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1914279/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915536] Re: one grub
** Description changed: [Impact] - * The proposal is to rename modules in -bin to be shipped in the - $platfrom-unsigned directory. + * The proposal is to split src:grub2 into two source packages - * And make -signed-bin package ship modules + src:grub2 will continue to build most things, apart from bin|dbg + |signing-tempate binary packages for platforms that get signed. - * And add dependency from the -bin onto > -signed-bin (>= $grub2-signed - stem) + src:grub2-unsigned source package is source-full copy of src:grub2 that + only builds bin|dbg|signing-tempate binary packages for platforms that + get signed and submits monolithic binaries for signing. - * This allows allows in the future for grub2-signed to pull appropriate - grub modules for a given distro. For example, using 2.04 modules & - signed images from focal on bionic to gain support for TPM verifies and - other EFI platform specific developments without affecting userspace - grub tooling. + src:grub2-signed is built as before, but its maintainer scripts should + be compatible across grub2-common from precise and up. + + Stable series will receive grub2 update that drops building bin|dbg + |signing-template. + + Stable series will receive binary-copy of grub2-unsigned & grub2-signed, + thus on signed platforms EFI apps and modules will be the same across + all series. + [Caveats] - * In devel series, keep grub2 submitting things for signing by setting - SB_SUBMIT := yes + * In devel series, always upload grub2 with matching src:grub2-unsigned + which can be build with ./debian/rules generate-grub2-unsigned command. - * With every new upload bump the version number of the -signed-bin (>= - $grub2-signed-ver) package, to the expected one from grub2-signed. + * In stable series, only upload src:grub2 when fixes needed in update- + grub / grub.cfg / grub-install / etc, but not in the efi modules & apps. - * Upload new grub2-signed with the version set above or higher, - vendoring the desired signed grub2. - - -- - - In stable series to disable submitting signing set SB_SUBMIT := no. - - Then one can upload grub2-signed first, followed by grub2. - - Upload grub2 to bump the version number of the -signed-bin (>= $grub2 - -signed-ver) dependency, to the expected one from grub2-signed. - - Upload new grub2-signed pulling whichever signed grub from whichever - series as needed. + * As needed, binary copy grub2-unsigned & grub2-signed from later series + to stable series. [Test Case] - * Upgrade to new grub-efi-amd64-bin and grub-efi-amd64-signed packages + * Upgrade to new packages * Observe that system boots, one can use grub-mkimage / grub-mkrescue without issues. [Where problems could occur] - * The binaries shipped by -signed packages are innert, they are - bootloader binaries only. The only compatibility that has to be - maintained is within the userspace tooling - specifically maintainer - scripts, and file names and locations. - - [Other Info] - - * See all the bug reports that grub can't be installed or upgraded when - people use -proposed. + * There might be regression on the EFI platforms with grub 2.04 that + have not so far been caught on Focal / Groovy / Hirsute. ** Description changed: [Impact] - * The proposal is to split src:grub2 into two source packages + The proposal is to split src:grub2 into two source packages. src:grub2 will continue to build most things, apart from bin|dbg |signing-tempate binary packages for platforms that get signed. src:grub2-unsigned source package is source-full copy of src:grub2 that only builds bin|dbg|signing-tempate binary packages for platforms that get signed and submits monolithic binaries for signing. src:grub2-signed is built as before, but its maintainer scripts should be compatible across grub2-common from precise and up. Stable series will receive grub2 update that drops building bin|dbg |signing-template. Stable series will receive binary-copy of grub2-unsigned & grub2-signed, thus on signed platforms EFI apps and modules will be the same across all series. - [Caveats] * In devel series, always upload grub2 with matching src:grub2-unsigned - which can be build with ./debian/rules generate-grub2-unsigned command. + and src:grub2-signed. The unsigned package can be build with + ./debian/rules generate-grub2-unsigned command from src:grub2. * In stable series, only upload src:grub2 when fixes needed in update- grub / grub.cfg / grub-install / etc, but not in the efi modules & apps. * As needed, binary copy grub2-unsigned & grub2-signed from later series to stable series. [Test Case] * Upgrade to new packages * Observe that system boots, one can use grub-mkimage / grub-mkrescue without issues. [Where problems could occur] * There might be regression on the EFI platforms with grub 2.04 that have not so far been caught on Focal
[Bug 1914574] Re: [21.04 FEAT] Upgrade s390-tools to latest version (2.16.0)
** Changed in: s390-tools (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914574 Title: [21.04 FEAT] Upgrade s390-tools to latest version (2.16.0) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914574/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1892367] Re: [UBUNTU 20.04] udev rule change did not get applied
** Changed in: s390-tools (Ubuntu Hirsute) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1892367 Title: [UBUNTU 20.04] udev rule change did not get applied To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1892367/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33
** Changed in: clucene-core (Ubuntu) Status: Triaged => In Progress ** Changed in: clucene-core (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913388 Title: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1887933] Re: [21.04 FEAT] wireshark: Update to include SMC support
** Information type changed from Private to Public ** Changed in: wireshark (Ubuntu) Status: Incomplete => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1887933 Title: [21.04 FEAT] wireshark: Update to include SMC support To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1887933/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
systemd-networkd has this option in systemd.network RequestBroadcast= Request the server to use broadcast messages before the IP address has been configured. This is necessary for devices that cannot receive RAW packets, or that cannot receive packets at all before an IP address has been configured. On the other hand, this must not be enabled on networks where broadcasts are filtered out. I wonder if in addition to netplan.yaml, one could manually create /etc/systemd/network/NETPLAN_GENERATED_NETWORK_NAME.network.d/ directory and drop in there 30-request-broadcast.conf [DHCPv4] RequestBroadcast=yes I wonder if that will make "everything work" Note that indeed this will only work for installed systems to communicate with each other. This will not work from the initrd to netboot the installer (aka ip=dhcp url=http://url/to/server-live.iso). I am slightly perplexed about this option. Is it possible to detect that interface is a hypersocket in L3? Shouldn't systemd-networkd default to RequestBroadcast=yes for such interfaces? Imho it would be not neat that one has to manually specify request-broadcast: true in netplan yaml. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
For netplan yaml of: network: version: 2 ethernets: enc8f00: dhcp4: yes It would be interesting to see if L3 dhcp starts to work if one does: $ sudo mkdir -p /etc/systemd/network/10-netplan-enc8f00.network.d $ cat
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
My preference would be to fix networkd, if that fails netplan, and isc- dhcp only if there is syntax to online the device in the right l2/l3 state via kernel cmdline and that one needs to complete install over it. For example, does automatic chzdev device enablement provides autoconfiguration for hipersockets in l3? in that case it would be neat for ip=dhcp to just do the right thing. ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Confirmed ** Changed in: netplan.io (Ubuntu) Status: New => Confirmed ** Also affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New ** Changed in: isc-dhcp (Ubuntu) Importance: Undecided => Low ** Changed in: isc-dhcp (Ubuntu) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Importance: Undecided => High ** Changed in: netplan.io (Ubuntu) Importance: Undecided => Low ** Changed in: isc-dhcp (Ubuntu) Importance: Low => Wishlist -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
Would turning on RequestBroadcast=yes for ID_NET_DRIVER=qeth_l3 interfaces be good enough in networkd? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1916749] Re: plf-colony simple.cc test fails with "stderr: dis_syslink(ppc)(theInstr)" on ppc64el with glibc 2.33
** Also affects: valgrind (Ubuntu) Importance: Undecided Status: New ** Changed in: glibc (Ubuntu) Status: New => Incomplete ** Changed in: plf-colony (Ubuntu) Status: New => Incomplete ** Changed in: valgrind (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1916749 Title: plf-colony simple.cc test fails with "stderr: dis_syslink(ppc)(theInstr)" on ppc64el with glibc 2.33 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916749/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913321] Re: [MIR] iniparser (dependency of mtd-utils)
man dh_clean: path ... Delete these paths too. Note that directories passed as arguments must end with a trailing slash. Any content in these directories will be removed as well. i don't think obj-$() without '/' at the end will work. Normally in override_dh_clean, dh_clean must be called last, otherwise it will wipe the state with the subsequent commands failing, and not remembering that it needs to rerun them. Thus it's always best to do override_dh_clean: random stuff dh_clean Also i'd rather you clean the test dir in "override_dh_auto_clean:" before calling regular dh_auto_clean. As that's the target meant for cleaning up the upstream build system mess. Also need to ignore result of that make call, i.e. "-make clean" -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913321 Title: [MIR] iniparser (dependency of mtd-utils) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iniparser/+bug/1913321/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
I've started drafting this patch. I want to prepare a PPA for you to try, can you please let me know which Ubuntu release is best / easiest for you to test? Hirsute? Focal? Bionic? ** Patch added: "dhcp_broadcast_qeth_l3.patch" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914740/+attachment/5467722/+files/dhcp_broadcast_qeth_l3.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
** Patch removed: "dhcp_broadcast_qeth_l3.patch" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914740/+attachment/5467722/+files/dhcp_broadcast_qeth_l3.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
** Patch added: "0001-s390x-For-qeth_l3-set-dhcp_broadcast-to-true-by-defa.patch" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914740/+attachment/5471481/+files/0001-s390x-For-qeth_l3-set-dhcp_broadcast-to-true-by-defa.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
** Patch added: "focal_qeth_l3_request_broadcast.patch" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1914740/+attachment/5471480/+files/focal_qeth_l3_request_broadcast.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
I have made this PPA https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4477 It has packages for focal versioned above current focal-updates version, but lower than the next SRU. sudo add-apt-repository ppa:ci-train-ppa-service/4477 sudo apt install systemd Should be enough to upgrade networkd. After that if you have installed network.d snippets you should remove them, and then reboot and things should just work. If reboot is too much doing chzdev -d / -e on the hipersocket interfaces that are in l3 should do the trick as well. After testing you can downgrade / remove those packages with ppa-purge, or just leave them until next SRU update arrives. If you can't use add-apt-repository (needs http(s) access to api.launchpad.net and ppa.launchpad.net) you can also download the .deb files from https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/4477/+build/21099271 and install them with $ sudo apt ./*.deb => do not it has to "absolute path names, or paths prefixed with ./" for apt to recognise them to install from local files instead of trying to fetch things from the mirror. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
https://github.com/systemd/systemd/pull/18829 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915005] Re: Please merge findutils 4.8.0 from Debian unstable
** Changed in: findutils (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915005 Title: Please merge findutils 4.8.0 from Debian unstable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1915005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915536] Re: one grub
** Changed in: grub2-signed (Ubuntu) Status: Fix Released => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915536 Title: one grub To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915536] Re: one grub
** Also affects: grub2 (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: grub2 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: grub2 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: grub2 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: grub2 (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: grub2-signed (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: grub2 (Ubuntu Xenial) Status: New => Fix Committed ** Changed in: grub2 (Ubuntu Bionic) Status: New => Fix Committed ** Changed in: grub2 (Ubuntu Focal) Status: New => Fix Committed ** Changed in: grub2 (Ubuntu Groovy) Status: New => Fix Committed ** Changed in: grub2 (Ubuntu Hirsute) Status: New => Fix Committed ** Changed in: grub2-signed (Ubuntu Xenial) Status: New => Fix Committed ** Changed in: grub2-signed (Ubuntu Bionic) Status: New => Fix Committed ** Changed in: grub2-signed (Ubuntu Focal) Status: New => Fix Committed ** Changed in: grub2-signed (Ubuntu Groovy) Status: New => Fix Committed ** Changed in: grub2-signed (Ubuntu Hirsute) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915536 Title: one grub To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915536] Re: one grub
** Merge proposal unlinked: https://code.launchpad.net/~xnox/grub/+git/grub/+merge/398407 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915536 Title: one grub To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1917555] [NEW] UC20 Online Key signing request for grub2-signed 1.164
Private bug reported: This is the UC20 Online Signing Key Request for grub2-signed Package versions: grub2-unsigned 2.04-1ubuntu42 grub2-signed 1.164 grub2 build PPA to copy from: https://launchpad.net/~canonical- foundations/+archive/ubuntu/uc20-build-ppa signing PPA to use: ~canonical-signing UC20 signed binaries staging ppa: https://launchpad.net/~canonical- foundations/+archive/ubuntu/uc20-staging-ppa Steps Todo: 1) ~canonical-signing to copy with binaries grub2-unsigned 2) await signing NB! do not copy grub2-signed at the same time, as build-depends will be satisfied from the archive, instead of PPA, as the package version of grub2 is unchanged, and will result in a miss-built. 3) source-only copy grub2-signed 4) canonical-signing to copy with binaries grub2 & grub2-signed to the staging ppa ** Affects: grub2-signed (Ubuntu) Importance: Undecided Status: New ** Information type changed from Public to Private ** Description changed: This is the UC20 Online Signing Key Request for grub2-signed Package versions: grub2-unsigned 2.04-1ubuntu42 - grub2-signed 1.142.8+uc20.1 + grub2-signed 1.164 grub2 build PPA to copy from: https://launchpad.net/~canonical- foundations/+archive/ubuntu/uc20-build-ppa signing PPA to use: ~canonical-signing UC20 signed binaries staging ppa: https://launchpad.net/~canonical- foundations/+archive/ubuntu/uc20-staging-ppa Steps Todo: 1) ~canonical-signing to copy with binaries grub2-unsigned 2) await signing NB! do not copy grub2-signed at the same time, as build-depends will be satisfied from the archive, instead of PPA, as the package version of grub2 is unchanged, and will result in a miss-built. 3) source-only copy grub2-signed 4) canonical-signing to copy with binaries grub2 & grub2-signed to the staging ppa -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1917555 Title: UC20 Online Key signing request for grub2-signed 1.164 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1917555/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1881006] Re: Incorrect ESP mount options
** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1881006 Title: Incorrect ESP mount options To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1881006/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
Fedora & Debian & Ubuntu implement openssl differently. In Ubuntu, as an Ubuntu-specific patch, we set default security level to 2, and prohibit protocols lower than TLSv1.2 / DTLSv1.2. This is documented in the Ubuntu manpages for OpenSSL http://manpages.ubuntu.com/manpages/hirsute/en/man3/SSL_CTX_set_security_level.3ssl.html """ The default security level can be configured when OpenSSL is compiled by setting -DOPENSSL_TLS_SECURITY_LEVEL=level. On Ubuntu, 2 is used. Level 2 Security level set to 112 bits of security. As a result RSA, DSA and DH keys shorter than 2048 bits and ECC keys shorter than 224 bits are prohibited. In addition to the level 1 exclusions any cipher suite using RC4 is also prohibited. On Ubuntu, TLS versions below 1.2 are not permitted. Compression is disabled. """ This is the only way that we have able to configure minimum key sizes, protocol versions for both TLS and DTLS without making any openssl cnf changes, whilst remaining compatible with both openssl cnf from 1.0.2x, 1.1.0x and 1.1.1x series. As min/max API calls are not available across all openssl series and software that allows to configure openssl cipherstrings but not min/max versions. If you need access to (D)TLS below 1.2 or weak cryptography you can use openssl 1.1.1 API to set_security level to 1. Or you can set CipherString to DEFAULT@SECLEVEL=1. Without modifying the software at all, libssl can be configured via envrionment variables too. I.e. exporting export OPENSSL_CONF=`pwd`/openssl.cnf cat openssl.cnf openssl_conf = default_conf [default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect [system_default_sect] CipherString = DEFAULT@SECLEVEL=1 Note that this openssl.cnf is compatible with _any_ openssl series. In debian, they set min versions of TLS communication only, which breaks with openssl 1.0.2x series as it fails to parse those settings. That was unacceptable for Ubuntu. I don't know how Fedora implements this, I guess I should take a look. It would be nice for OpenSSL upstream to provide a standard configure time option to set these things in a consistent manner, as at the moment each distribution has to invent their own way of doing this. My proposals to bump minimum protocol versions to TLSv1.2 in OpenSSL 3.0.0 for the time being got rejected, as it is deemed too soon. In Ubuntu, we also configure GnuTLS with similar parameters, the override mechanism there is different see https://discourse.ubuntu.com/t /default-to-tls-v1-2-in-all-tls-libraries-in-20-04-lts/12464/8 for both OpenSSL and GnuTLS details. I'm not sure what is expected from this bug report. Ubuntu changes are documented and publicized and are trivial to find. Were you expecting to find this documentation somewhere else? Where did you look? I am happy to add more documentation in more places, or change the implementation. What does Fedora do? And is it portable to distributions that do not use the crypto-policies package to maintain configs? ** Changed in: openssl (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
But Debian & Fedora implementation are buggy, because they break 1.0.2x users & they do not prohibit DTLSv1.1 whilst enforcing TLSv1.2+. So although Debian & Fedora look "nice" they are security vulnerable configurations. I can set min_version to TLSv1.2, in addition to security level 2 but that will not make current stable test_ssl test suite pass, as it will require not only changing min_level but also setting security level to 1. I do not see a way to make things secure, for both TLS and DTLS, and discoverable and not pain to use. Because when default context is created it is not known if TLS or DTLS will be used, and the enums for TLS & DTLS are not compatible with each other. Ultimately it is deficiency in the OpenSSL APIs because it is impossible to know what is or isn't allowed by a given client OpenSSL context, against which server context, and vice versa. Even when enums are available, and one sets them as appropriate min/max. There are no inspection APIs available into the security levels. For example, it impossible to query if ones client certificate is suitable for a given security level, apart from trying to establish the connection. Re Kurt => i have spoken to Kurt about this, he is aware that Debian's implementation is buggy and he does prefer Ubuntu's one, however Ubuntu's one is not without drawbacks either. I.e. at the moment in Debian people simply choose to not install openssl package and thus end up operating without public certificates and with TLS v1.1/v1.0 enabled, meaning the system is insecure by accident against the intentions. Especially if one tries to be secure, and use private CA certificates only. """ 2) With some configuration, OpenSSL's SSL_do_handshake() function fails with an "internal error" message (SSL_AD_INTERNAL_ERROR / TLS1_AD_INTERNAL_ERROR) somewhere in its internal state machine. """ I'm not sure how this is related to anything of the above, can you please open a new bug report with details? crashes in handshake are typically specific to the connection type, context on both client & server, and well bugs. The one thing that I know failing badly, is when server has redundant tls certificates in its chain that are considered insecured (i.e. old CA cross-signed new CA). And OpenSSL client currently rejects establishing the connection, despite the server chain having alternative paths of certs that are secure throughout. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1915536] Re: one grub
** Tags added: block-proposed block-proposed-hirsute -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1915536 Title: one grub To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1915536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928648] [NEW] expiring trust anchor compatibility issue
*** This bug is a security vulnerability *** Public security bug reported: https://community.letsencrypt.org/t/openssl-client-compatibility- changes-for-let-s-encrypt-certificates/143816 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 ** Affects: gnutls28 (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: gnutls28 (Ubuntu Precise) Importance: Undecided Status: New ** Affects: gnutls28 (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: gnutls28 (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: gnutls28 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: gnutls28 (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: gnutls28 (Ubuntu) Status: New => Fix Released ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928674] [NEW] due to a new recommends grub-efi-arm64-signed is installed which does not have postinst.d script
*** This bug is a security vulnerability ***
Public security bug reported:
[Impact]
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
with grub-efi-arm64-signed installed, without grub-efi-arm64.
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64.
* This results in newly installed kernels not getting added to grub.cfg
and thus upon reboot one does not boot into the new kernel.
* In later series these scripts moved to grub2-common. Maybe we should
move these to grub2-common in bionic and earlier too, for compatibility
with onegrub. Or alternatively grub2-signed should ship these in grub-
efi-{amd64,arm64}-signed packages too.
[Test Plan]
* Install new grubs
* Install a new kernel that was not installed before
* Observe that grub.cfg is regenerated and new kernel is present
* Remove an old kernel
* Observe that grub.cfg is regenerated and new kernel is removed from
grub.cfg
[Where problems could occur]
* These are conffiles. Although nobody should modify them, care should
be taken when moving conffiles around.
[Other Info]
* First reported by klebers
** Affects: grub2-signed (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: grub2-signed (Ubuntu Trusty)
Importance: Undecided
Status: Triaged
** Affects: grub2-signed (Ubuntu Xenial)
Importance: Undecided
Status: Triaged
** Affects: grub2-signed (Ubuntu Bionic)
Importance: Undecided
Status: Triaged
** Also affects: grub2-signed (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: grub2-signed (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: grub2-signed (Ubuntu Bionic)
Importance: Undecided
Status: New
** Information type changed from Public to Public Security
** Changed in: grub2-signed (Ubuntu)
Status: New => Fix Released
** Changed in: grub2-signed (Ubuntu Trusty)
Status: New => Triaged
** Changed in: grub2-signed (Ubuntu Xenial)
Status: New => Triaged
** Changed in: grub2-signed (Ubuntu Bionic)
Status: New => Triaged
** Description changed:
[Impact]
- * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
+ * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
with grub-efi-arm64-signed installed, without grub-efi-arm64.
- * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
+ * /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64.
- * This results in newly installed kernels not getting added to grub.cfg
+ * This results in newly installed kernels not getting added to grub.cfg
and thus upon reboot one does not boot into the new kernel.
- * In later series these scripts moved to grub2-common. Maybe we should
+ * In later series these scripts moved to grub2-common. Maybe we should
move these to grub2-common in bionic and earlier too, for compatibility
- with onegrub.
-
+ with onegrub. Or alternatively grub2-signed should ship these in grub-
+ efi-{amd64,arm64}-signed packages too.
[Test Plan]
- * Install new grubs
+ * Install new grubs
- * Install a new kernel that was not installed before
+ * Install a new kernel that was not installed before
- * Observe that grub.cfg is regenerated and new kernel is present
+ * Observe that grub.cfg is regenerated and new kernel is present
- * Remove an old kernel
+ * Remove an old kernel
- * Observe that grub.cfg is regenerated and new kernel is removed from
+ * Observe that grub.cfg is regenerated and new kernel is removed from
grub.cfg
[Where problems could occur]
- * These are conffiles. Although nobody should modify them, care should
+ * These are conffiles. Although nobody should modify them, care should
be taken when moving conffiles around.
[Other Info]
-
- * First reported by klebers
+
+ * First reported by klebers
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928674
Title:
due to a new recommends grub-efi-arm64-signed is installed which does
not have postinst.d script
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1928674/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928674] Re: due to a new recommends grub-efi-arm64-signed is installed which does not have postinst.d script
** Description changed:
[Impact]
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on arm64
with grub-efi-arm64-signed installed, without grub-efi-arm64.
* /etc/kernel/{postinst.d,postrm.d}/zz-update-grub missing on amd64
with grub-efi-amd64-signed installed without grub-pc or grub-efi-amd64.
* This results in newly installed kernels not getting added to grub.cfg
and thus upon reboot one does not boot into the new kernel.
* In later series these scripts moved to grub2-common. Maybe we should
move these to grub2-common in bionic and earlier too, for compatibility
with onegrub. Or alternatively grub2-signed should ship these in grub-
efi-{amd64,arm64}-signed packages too.
[Test Plan]
* Install new grubs
+ * If testing on arm64 ensure that grub-efi-arm64 is not installed; and
+ grub-efi-arm64-signed is installed.
+
+ * If testing on amd64 ensure that grub-efi-amd64 and grub-pc are not
+ installed; and grub-efi-amd64-signed is installed.
+
* Install a new kernel that was not installed before
* Observe that grub.cfg is regenerated and new kernel is present
* Remove an old kernel
* Observe that grub.cfg is regenerated and new kernel is removed from
grub.cfg
[Where problems could occur]
* These are conffiles. Although nobody should modify them, care should
be taken when moving conffiles around.
[Other Info]
* First reported by klebers
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928674
Title:
due to a new recommends grub-efi-arm64-signed is installed which does
not have postinst.d script
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1928674/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928679 Title: Support importing mokx keys into revocation list from the mok table To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928679/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1914279 Title: linux from security may force reboots without complete dkms modules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1914279/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928434] Re: shim-signed does not boot on EFI 2.40 by Apple
@kebkeb you can download that efivariable as a file into the efivars dir. Or you need to compile the new mokutil that supports setting that on non-secureboot systems too. See https://github.com/lcp/mokutil/commit/03bb7af4a84c39f2417fd14ef20b11b2e8d1ad51 Is this something you can compile yourself, or do you need me to provide you with an updated mokutil package? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928434 Title: shim-signed does not boot on EFI 2.40 by Apple To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1928434/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903288 Title: Power guest secure boot with static keys: kernel portion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903288 Title: Power guest secure boot with static keys: kernel portion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903288 Title: Power guest secure boot with static keys: kernel portion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903288 Title: Power guest secure boot with static keys: kernel portion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1903288 Title: Power guest secure boot with static keys: kernel portion To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1903288/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928674] Re: grub-efi-amd64 from grub2-unsigned has lost kernel/postinst.d script
How can you introduce conffiles in grub-efi-amd64 & grub-efi-arm64 which
is shared across releases? If in later series they have been removed
from said package. That will cause a mess in focal+ then, since it will
conflict with grub2-common there.
Given that the future is for these conffiles to live in grub2-common, it
might be easier to backport the move from grub-{platform} to
grub2-common.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1928674
Title:
grub-efi-amd64 from grub2-unsigned has lost kernel/postinst.d script
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/1928674/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928648] Re: expiring trust anchor compatibility issue
** Description changed: - https://community.letsencrypt.org/t/openssl-client-compatibility- - changes-for-let-s-encrypt-certificates/143816 + https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 + https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928648] Re: expiring trust anchor compatibility issue
** Description changed: + [Impact] + + * gnutls28 fails to talk to letsencrypt website past September 2021, + despite trusting the letsencrypt root certificate. + + [Test Plan] + + * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem + + * Import expired staging cert equivalen tto DST Root CA X3 + https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem + + + * Test connectivity to the expired-root-ca test website + https://expired-root-ca-test.germancoding.com + + + [Where problems could occur] + + * Changes as to how the trust paths are built in TLS connection may + result in introducing bugs (failure to connect to valid sites) and/or + security vulnerabilities (connecting to invalid sites successfully). + + [Other Info] + + * Background info + * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. + https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928648] Re: expiring trust anchor compatibility issue
** Description changed: [Impact] - * gnutls28 fails to talk to letsencrypt website past September 2021, + * gnutls28 fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] - * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem - - * Import expired staging cert equivalen tto DST Root CA X3 - https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem + * Import staging cert equivalent to ISRG Root X1 + https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem + + * Import expired staging cert equivalen tto DST Root CA X3 + https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem + + * Test connectivity to the expired-root-ca test website + https://expired-root-ca-test.germancoding.com - * Test connectivity to the expired-root-ca test website - https://expired-root-ca-test.germancoding.com + wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem + wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem + cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem + gnutls-cli --x509cafile=ca.pem https://expired-root-ca-test.germancoding.com/ + + Connection should be successful and trusted with correctly working + gnutls client that can manage to ignore expired CA, and build a valid + trust path using non-expired CA in the chain. [Where problems could occur] - * Changes as to how the trust paths are built in TLS connection may + * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] - - * Background info - * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. + + * Background info + * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 ** Description changed: [Impact] * gnutls28 fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com - + apt install wget gnutls-bin wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem gnutls-cli --x509cafile=ca.pem https://expired-root-ca-test.germancoding.com/ Connection should be successful and trusted with correctly working gnutls client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. - [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Curr
[Bug 1928648] Re: expiring trust anchor compatibility issue
** Tags added: letsencrypt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928989] [NEW] expiring trust anchor compatibility issue
Public bug reported: [Impact] * openssl fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com setup: apt install openssl wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem test case: openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem bad result: connection failed good result: connection successful Connection should be successful and trusted with correctly working openssl s_client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently openssl in xenial and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 ** Affects: openssl (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: openssl (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: openssl (Ubuntu Xenial) Importance: Undecided Status: New ** Tags: letsencrypt ** Also affects: openssl (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: openssl (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928989 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928989] Re: expiring trust anchor compatibility issue
** Information type changed from Public to Public Security ** Tags removed: letsencrypt ** Tags added: letsencryptexpiry -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928989 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928648] Re: expiring trust anchor compatibility issue
** Description changed: [Impact] * gnutls28 fails to talk to letsencrypt website past September 2021, despite trusting the letsencrypt root certificate. [Test Plan] * Import staging cert equivalent to ISRG Root X1 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem * Import expired staging cert equivalen tto DST Root CA X3 https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem * Test connectivity to the expired-root-ca test website https://expired-root-ca-test.germancoding.com setup: apt install wget gnutls-bin wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem test case: gnutls-cli --x509cafile=ca.pem expired-root-ca-test.germancoding.com bad result: - - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. + - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate. good result: - - Status: The certificate is trusted. + - Status: The certificate is trusted. - Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) - Session ID: A8:2B:AF:85:54:64:3A:79:81:99:16:D4:6D:9A:FC:30:F1:EC:49:A4:09:A9:0C:31:37:38:C2:0E:73:C7:C9:04 - Options: OCSP status request, - Handshake was completed Connection should be successful and trusted with correctly working gnutls client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain. [Where problems could occur] * Changes as to how the trust paths are built in TLS connection may result in introducing bugs (failure to connect to valid sites) and/or security vulnerabilities (connecting to invalid sites successfully). [Other Info] * Background info * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021. https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816 https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817 Currently gnutls28 in bionic and earlier will not establish a connection, if any parts of the trust chain have expired, even though alternative non-expired chains are available. This has been fixed in GnuTLS 3.6.14, but probably should be backported to bionic and earlier if it was not already been done so. https://gitlab.com/gnutls/gnutls/-/issues/1008 https://gitlab.com/gnutls/gnutls/-/merge_requests/1271 + + Openssl bug report for this issue is + https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 ** Tags removed: letsencrypt ** Tags added: letsencryptexpiry -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928648 Title: expiring trust anchor compatibility issue To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928674] Re: grub-efi-amd64 from grub2-unsigned has lost kernel/postinst.d script
Steve I'm not sure one gets valid grub2 binaries by building with bionic's toolchain on neither amd64 nor arm64. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928674 Title: grub-efi-amd64 from grub2-unsigned has lost kernel/postinst.d script To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1928674/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1929059] [NEW] Maybe needs update for smbios handling
Public bug reported: Currently this package generates /boot/grub/gfxblacklist.txt which is processed with hwmatch which is only available on grub-pc platform and not on the uefi platform. on uefi platform we instead have smbios command. Can we update grub-gfxpayload-lists & grub to generate something using smbios command instead? Also do we still need this package? I am not too sure if the vendors in question are still relevant hardware. This also currently generates ugly messages during every boot of every ubuntu release stating that `hwmatch command is not available`. ** Affects: grub-gfxpayload-lists (Ubuntu) Importance: Undecided Status: New ** Affects: grub2 (Ubuntu) Importance: Undecided Status: New ** Tags: papercut rls-ii-incoming ux ** Tags added: papercut rls-ii-incoming ux ** Also affects: grub2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929059 Title: Maybe needs update for smbios handling To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub-gfxpayload-lists/+bug/1929059/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1929059] Re: Maybe needs update for smbios handling
** Description changed: Currently this package generates /boot/grub/gfxblacklist.txt which is processed with hwmatch which is only available on grub-pc platform and not on the uefi platform. on uefi platform we instead have smbios command. Can we update grub-gfxpayload-lists & grub to generate something using - smbios command instead? + smbios command instead? Or at the very least the calls to hwmatch should + be guarded and done on grub pc platform only. Also do we still need this package? I am not too sure if the vendors in question are still relevant hardware. This also currently generates ugly messages during every boot of every ubuntu release stating that `hwmatch command is not available`. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929059 Title: Maybe needs update for smbios handling To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub-gfxpayload-lists/+bug/1929059/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1928709] Re: Can't launch hirsute VM using LXD
i still want to somehow eliminate efivars being missbuilt and not garbage collected. separately juliank is working on making shim _not_ mirror variables which should make things better. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928709 Title: Can't launch hirsute VM using LXD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1928709/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1929413] [NEW] linux-aws-hwe missing from bionic+ failing to upgrade from xenial on arm64
Public bug reported: linux-aws-hwe missing from bionic+ failing to upgrade from xenial on arm64 Possibly linux-aws must specify migration flavours, on arm64 from linux- aws-hwe to linux-aws. ** Affects: linux-meta-aws-hwe (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929413 Title: linux-aws-hwe missing from bionic+ failing to upgrade from xenial on arm64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta-aws-hwe/+bug/1929413/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1929413] Re: aws arm64 shipped tracking linux-aws-edge and never rolled off
** Summary changed: - linux-aws-hwe missing from bionic+ failing to upgrade from xenial on arm64 + aws arm64 shipped tracking linux-aws-edge and never rolled off ** Description changed: - linux-aws-hwe missing from bionic+ failing to upgrade from xenial on - arm64 + Looks like xenial instances will continue to track linux-aws-edge, and + not switch to linux-aws upon dist upgrade. - Possibly linux-aws must specify migration flavours, on arm64 from linux- - aws-hwe to linux-aws. + It seems that maybe we should add a quirk to change people from linux- + aws-edge to linux-aws when doing do-release-upgrade on arm64 from xenial + to bionic. ** Summary changed: - aws arm64 shipped tracking linux-aws-edge and never rolled off + aws arm64 shipped tracking linux-aws-edge in xenial and never rolled off ** Also affects: ubuntu-release-upgrader (Ubuntu) Importance: Undecided Status: New ** Also affects: cloud-images Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929413 Title: aws arm64 shipped tracking linux-aws-edge in xenial and never rolled off To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1929413/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1929413] Re: aws arm64 shipped tracking linux-aws-edge in xenial and never rolled off
** Tags added: bionic xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929413 Title: aws arm64 shipped tracking linux-aws-edge in xenial and never rolled off To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1929413/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1925209] Re: No iwilwifi driver in Linux 5.4.0-1034-raspi
Hi, 5.4.0-1036.39 kernel is in focal-proposed. As a snap it is in 20/beta channel. You should be able to refresh pi-kernel from --channel 20/beta. If that doesn't work, please boot and try one of the daily beta images for your board. Regards, Dimitri. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1925209 Title: No iwilwifi driver in Linux 5.4.0-1034-raspi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1925209/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1929213] Re: Ubuntu server LVM creates clone partitions and crash installation
wwn: '0x5000' is not a valid wwn and should have been rejected by udev & probert. All zeros are not allowed, and 5 is just a prefix. I think this is an OEM / whitelabel drive, with expectation that somebody who ships these drives will use their WWN prefix and flash their own WWN as they see fit. If they cared. ** Summary changed: - Ubuntu server LVM creates clone partitions and crash installation + Ubuntu server LVM creates clone partitions and crash installation (invalid wwn is used by udev & probert as well) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929213 Title: Ubuntu server LVM creates clone partitions and crash installation (invalid wwn is used by udev & probert as well) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1929213/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929255 Title: update-initrd-links creates incorrect symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1928700 Title: new postinst hook requires initramfs-tools To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1928700/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877088/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929255 Title: update-initrd-links creates incorrect symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929255
Title:
update-initrd-links creates incorrect symlinks
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1929255
Title:
update-initrd-links creates incorrect symlinks
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929255 Title: update-initrd-links creates incorrect symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877088/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929255 Title: update-initrd-links creates incorrect symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1929255 Title: update-initrd-links creates incorrect symlinks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1929255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
