[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added:
"0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607435/+files/0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320
* Test source code: https://github.com/os369510/grub2/tree/lp1842320
* If you built the package
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added:
"0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607434/+files/0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320
* Test source code: https://github.com/os369510/grub2/tree/lp1842320
* If you built the package
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
This patch is not from upstream or rhboot but which has been submitted as a MP
to rhboot
https://github.com/rhboot/grub2/pull/102
+0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch
+0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch
+0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch
+0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch
+0133-x86-efi-Allow-initrd-params-cmdline-allocations-abov.patch
+0134-linuxefi-fail-kernel-validation-without-shim-protoco.patch
+0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch
0129-0134 are from rhboot.
** Patch added: "0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607436/+files/0135-Fix-4GB-memory-be-filtered-out-by-filter_memory_map.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOC
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607433/+files/0132-x86-efi-Make-our-own-allocator-for-kernel-stuff.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320
* Test source code: https://github.com/os369510/grub2/tree/lp1842320
* If you built the package, then test
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added: "0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607432/+files/0131-x86-efi-Re-arrange-grub_cmd_linux-a-little-bit.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320
* Test source code: https://github.com/os369510/grub2/tree/lp1842320
* If you built the package, then test g
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
** Patch added:
"0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607431/+files/0130-x86-efi-Use-bounce-buffers-for-reading-to-addresses-.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
https://people.canonical.com/~jeremysu/lp1842320/grubx64.efi.lp1842320
* Test source code: https://github.com/os369510/grub2/tree/lp1842320
* If you built the package
[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
As my MP from comment#69 doesn't have response from rhboot team.
Shared the debdiff here for review to consider to carry it in Ubuntu.
** Patch added: "0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/+attachment/5607429/+files/0129-Try-to-pick-better-locations-for-kernel-and-initrd.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
https://people.canonical.com/~jeremysu/lp
[Touch-packages] [Bug 1981622] Re: mtd device must be supplied (device name is empty)
Just received more updates and back to the same issue. 167.047420 MTD
device name must be supplied (device name is empty) stuck at username
prompt.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981622
Title:
mtd device must be supplied (device name is empty)
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Confirmed
Status in systemd source package in Jammy:
Confirmed
Bug description:
[WORKAROUND]
This will NOT fix a system that is not booting, because the "mtd
device must be supplied (device name is empty)" message is not the
cause of failed boots. This work around is only for those who are
annoyed by the error message, but are otherwise not experiencing any
issues.
If you are not able to boot your system, but you see this error
message, please open a separate bug with your journalctl and dmesg
logs.
# cp /{lib,etc}/systemd/system/systemd-pstore.service
# sed -i 's/modprobe@mtdpstore.service //'
/etc/systemd/system/systemd-pstore.service
# systemctl daemon-reload
[Impact]
Due to mtdpstore not being properly configured as a pstore backend,
when systemd-pstore.service tries to load the module, users get the
following error in dmesg:
[ 18.453473] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 18.462685] mtd device must be supplied (device name is empty)
This is a distracting error for users trying to diagnose other system
issues, especially if their system does not boot after a kernel crash
and this is the only message displayed on the console.
[Test Plan]
* Force a kernel crash to populate /sys/fs/pstore, thus causing
systemd-pstore.service to start on the subsequent boot:
# echo 1 > /proc/sys/kernel/sysrq
# echo 1 > /proc/sys/kernel/panic
# echo c > /proc/sysrq-trigger
* When the system reboots, observe the error in dmesg:
# dmesg | grep mtd
[Where problems could occur]
If a system was relying on this pstore backend, and mtdpstore is built
as a module, it is possible for systemd-pstore.service to trigger
before mtdpstore is loaded, causing systemd-pstore to not copy the
contents of /sys/fs/pstore. Note however that before the patched
introduced as a result of bug 1978079, systemd-pstore.service would
not attempt to load *any* kernel modules.
[Original Description]
After updating my 22.04 system (possibly caused by Systemd update).
And now booting, dmesg has two errors:
'mtd device must be supplied (device name is empty)'.
See line 8 and 134 in the included logfile.
The system are booting as it should though, and the system are working
like it should no errors at all.
Is this maybe caused by 'efi-pstore-not-cleared-on-boot.patch' in
systemd?
I have an EFI mounted at boot but it isn't used because I have
installed my system in legacy BIOS mode.
Is this maybe the culprit?
I could ignore the message but it isn't nice though.
Regards
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1981622/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983529] Re: No sound after upgrade to prerelease Kinetic (Thinkpad X1E Gen 4)
*** This bug is a duplicate of bug 1979113 *** https://bugs.launchpad.net/bugs/1979113 This was fixed by installing wireplumber, so I think it's a duplicate of https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1979113 ** This bug has been marked a duplicate of bug 1979113 Kinetic sound disappeared after today updates -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1983529 Title: No sound after upgrade to prerelease Kinetic (Thinkpad X1E Gen 4) Status in alsa-driver package in Ubuntu: New Bug description: Not sure if it's relevant, but there are some errors in dmesg: $ sudo dmesg | grep audio [ 14.290226] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [ 14.440430] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [ 14.445129] sof-audio-pci-intel-tgl :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 14.445811] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100 [ 14.445861] sof-audio-pci-intel-tgl :00:1f.3: init of i915 and HDMI codec failed [ 14.448966] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode [ 15.467232] sof-audio-pci-intel-tgl :00:1f.3: codec #2 probe error, ret: -5 [ 15.467478] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 1 [ 15.467479] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver skl_hda_dsp_generic now [ 15.467484] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT tables: 2 [ 15.478062] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:1:1-3964a [ 15.478066] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:21:0 Kernel ABI 3:18:0 [ 15.478068] sof-audio-pci-intel-tgl :00:1f.3: warn: FW ABI is more recent than kernel [ 15.478073] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header type 3 size 0x30 [ 15.584074] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:1:1-3964a [ 15.584079] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:21:0 Kernel ABI 3:18:0 [ 15.584080] sof-audio-pci-intel-tgl :00:1f.3: warn: FW ABI is more recent than kernel [ 15.591457] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:21:0 Kernel ABI 3:18:0 [ 15.591461] sof-audio-pci-intel-tgl :00:1f.3: warn: topology ABI is more recent than kernel [ 15.624250] sof-audio-pci-intel-tgl :00:1f.3: ASoC: Parent card not yet available, widget card binding deferred [ 15.643720] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [ 15.643726] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.643727] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 15.643728] snd_hda_codec_realtek ehdaudio0D0:mono: mono_out=0x0 [ 15.643729] snd_hda_codec_realtek ehdaudio0D0:inputs: [ 15.643730] snd_hda_codec_realtek ehdaudio0D0: Mic=0x19 Because of those ABI warnings, I tried building the latest mainline kernel from source, and the ABI warnings went away, but I still have no sound. $ sudo dmesg | grep audio # On latest upstream kernel [ 17.519958] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [ 17.804900] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100 [ 17.805661] sof-audio-pci-intel-tgl :00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 17.806225] sof-audio-pci-intel-tgl :00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100 [ 17.806265] sof-audio-pci-intel-tgl :00:1f.3: init of i915 and HDMI codec failed [ 17.808071] sof-audio-pci-intel-tgl :00:1f.3: use msi interrupt mode [ 21.844005] sof-audio-pci-intel-tgl :00:1f.3: codec #2 probe error, ret: -5 [ 21.844263] sof-audio-pci-intel-tgl :00:1f.3: hda codecs found, mask 1 [ 21.844264] sof-audio-pci-intel-tgl :00:1f.3: using HDA machine driver skl_hda_dsp_generic now [ 21.844267] sof-audio-pci-intel-tgl :00:1f.3: DMICs detected in NHLT tables: 2 [ 21.853970] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:1:1-3964a [ 21.853971] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:21:0 Kernel ABI 3:21:0 [ 21.853979] sof-audio-pci-intel-tgl :00:1f.3: unknown sof_ext_man header type 3 size 0x30 [ 21.961252] sof-audio-pci-intel-tgl :00:1f.3: Firmware info: version 2:1:1-3964a [ 21.961255] sof-audio-pci-intel-tgl :00:1f.3: Firmware: ABI 3:21:0 Kernel ABI 3:21:0 [ 21.967719] sof-audio-pci-intel-tgl :00:1f.3: Topology: ABI 3:21:0 Kernel ABI 3:21:0 [ 21.979145] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC287: l
[Touch-packages] [Bug 1982545] Re: FTBFS on riscv64
This bug was fixed in the package curl - 7.84.0-2ubuntu1 --- curl (7.84.0-2ubuntu1) kinetic; urgency=medium * d/patches: Fix atomic use for RISC-V (LP: #1982545) -- Alexandre Ghiti Thu, 21 Jul 2022 18:59:11 +0200 ** Changed in: curl (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1982545 Title: FTBFS on riscv64 Status in curl package in Ubuntu: Fix Released Status in curl package in Debian: New Bug description: As can be seen here [1], the build on riscv64 fails now that we use gcc12 with the following error: libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Werror-implicit-function-declaration -Wno-system-headers -Wl,-Bsymbolic-functions -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/curl slist_wc.o tool_binmode.o tool_bname.o tool_cb_dbg.o tool_cb_hdr.o tool_cb_prg.o tool_cb_rea.o tool_cb_see.o tool_cb_wrt.o tool_cfgable.o tool_dirhie.o tool_doswin.o tool_easysrc.o tool_filetime.o tool_findfile.o tool_formparse.o tool_getparam.o tool_getpass.o tool_help.o tool_helpers.o tool_hugehelp.o tool_libinfo.o tool_listhelp.o tool_main.o tool_msgs.o tool_operate.o tool_operhlp.o tool_panykey.o tool_paramhlp.o tool_parsecfg.o tool_progress.o tool_strdup.o tool_setopt.o tool_sleep.o tool_urlglob.o tool_util.o tool_vms.o tool_writeout.o tool_writeout_json.o tool_xattr.o ../lib/strtoofft.o ../lib/timediff.o ../lib/nonblock.o ../lib/warnless.o ../lib/curl_ctype.o ../lib/curl_multibyte.o ../lib/version_win32.o ../lib/dynbuf.o ../lib/.libs/libcurl.so -lssl -lcrypto -lz /usr/bin/ld: ../lib/.libs/libcurl.so: undefined reference to `__atomic_exchange_1' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:991: curl] Error 1 There exists a bug report and a fix for that upstream here: https://github.com/curl/curl/pull/9061 I'm currently building a package with this patch here [2]. [1] https://launchpadlibrarian.net/612746451/buildlog_ubuntu-kinetic-riscv64.curl_7.84.0-2_BUILDING.txt.gz [2] https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+sourcepub/13822857/+listing-archive-extra To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1982545/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983998] Re: USB sound card not detected
Unfortunately, from what I'm reading in the description and logs, it appears as though this USB device isn't "standards compliant", meaning it reports values outside of the standard range that Apple created and Linux adopted for audio devices to be driverless. I'm seeing these warnings: > Warning! Unlikely big volume range (=496), cval->res is probably wrong. > Warning! Unlikely big volume range (=1008), cval->res is probably wrong. This is something we don't see on compatible audio devices with the Linux kernel. Basically, this means the USB-C lavalier microphones you bought, while they work with Windows, likely don't work without special tweaking in either macOS or Linux. Unfortunately, because of this, that means they're in a very narrow set of audio devices that are not supported. As an audio expert myself (leader of Ubuntu Studio, 28 years in production and professional audio), I'd suggest getting a good set of regular lavalier microphones and a decent audio interface. You'll likely run into trouble by using an all-in-one USB lavalier microphone. For further support, consult appropriate forums as bug trackers are no place for support. ** Changed in: alsa-driver (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1983998 Title: USB sound card not detected Status in alsa-driver package in Ubuntu: Invalid Bug description: usbc mics https://www.boya-mic.com/lavaliermicrophones/1430.html connects and immediately disconnects, ls usb hangs for a while, when usbc device is connected. it works on win laptop well. ``` [10877.622942] usb 3-4: new full-speed USB device number 28 using xhci_hcd [10877.779590] usb 3-4: New USB device found, idVendor=0c76, idProduct=153f, bcdDevice= 1.00 [10877.779596] usb 3-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [10877.779599] usb 3-4: Product: USB PnP Audio Device [10877.983589] usb 3-4: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10877.983593] usb 3-4: [51] FU [Mic Playback Volume] ch = 1, val = 0/7936/16 [10878.009593] usb 3-4: Warning! Unlikely big volume range (=1008), cval->res is probably wrong. [10878.009597] usb 3-4: [49] FU [Speaker Playback Volume] ch = 2, val = -16129/-1/16 [10878.035587] usb 3-4: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.035591] usb 3-4: [50] FU [Mic Capture Volume] ch = 1, val = 0/7936/16 [10878.038757] input: USB PnP Audio Device as /devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:06:00.3/usb3/3-4/3-4:1.3/0003:0C76:153F.001B/input/input45 [10878.095081] hid-generic 0003:0C76:153F.001B: input,hidraw6: USB HID v1.00 Device [USB PnP Audio Device] on usb-:06:00.3-4/input3 [10878.095179] usb 3-3: USB disconnect, device number 27 [10878.426945] usb 3-3: new full-speed USB device number 29 using xhci_hcd [10878.587590] usb 3-3: New USB device found, idVendor=0c76, idProduct=153f, bcdDevice= 1.00 [10878.587597] usb 3-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [10878.587599] usb 3-3: Product: USB PnP Audio Device [10878.783592] usb 3-3: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.783597] usb 3-3: [51] FU [Mic Playback Volume] ch = 1, val = 0/7936/16 [10878.809597] usb 3-3: Warning! Unlikely big volume range (=1008), cval->res is probably wrong. [10878.809601] usb 3-3: [49] FU [Speaker Playback Volume] ch = 2, val = -16129/-1/16 [10878.835592] usb 3-3: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.835596] usb 3-3: [50] FU [Mic Capture Volume] ch = 1, val = 0/7936/16 [10878.838754] input: USB PnP Audio Device as /devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:06:00.3/usb3/3-3/3-3:1.3/0003:0C76:153F.001C/input/input46 [10878.895092] hid-generic 0003:0C76:153F.001C: input,hidraw5: USB HID v1.00 Device [USB PnP Audio Device] on usb-:06:00.3-3/input3 [10878.895190] usb 3-4: USB disconnect, device number 28 ``` ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-45.48-generic 5.15.39 Uname: Linux 5.15.0-45-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: vany 12211 F pulseaudio /dev/snd/controlC0: vany 12211 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Aug 8 18:28:32 2022 InstallationDate: Installed on 2020-11-26 (619 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Title: USB sound card not detecte
[Touch-packages] [Bug 1615381] Re: apt-get autoremove may remove current kernel
The latter option sounds nicer. BTW can someone comment on https://bugs.launchpad.net/ubuntu/+source/ppa-purge/+bug/1392954 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1615381 Title: apt-get autoremove may remove current kernel Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt source package in Hirsute: Fix Released Bug description: [Impact] APT will try and fail to remove the currently running kernel, when booted into an older kernel that is not protected. May wreak some havoc if mixed with other operations to the point that apt goes weird and needs manual fixing up. [Test case] For the SRUs we have included an automated test case that starts with an empty autoremove config file, and then checks that the running kernel is protected at runtime. You can also test manually, but it's not necessary: - Install new kernel - Reboot into kernel not listed as protected in 01autoremove-kernels - Run autoremove [Where problems could occur] We may more easily run out of space in /boot. hirsute has new autoremoval code that runs completely at runtime; but that seems a bit large to SRU after only a few weeks in hirsute. Hence, we should protect the current kernel _in addition_ to the other kernels, just like unattended-upgrades and update-manager do. This increases the risk of filling up /boot compared to older apt versions, but is at the same level as unattended-upgrades and update-manager. [Original bug report] This may happen, if you boot one of the older kernels, that is not protected by /etc/apt/apt.conf.d/01autoremove-kernels Workaround: run /etc/kernel/postinst.d/apt-auto-removal during each boot (e.g. by using cron). Note: The workaround breaks autoremoving feature of new unneeded kernels in unattended-upgrades i.e. the setting 'Unattended-Upgrade::Remove-New-Unused-Dependencies "true"' (which is default in 16.04 unless 'Unattended-Upgrade::Remove-Unused-Dependencies "true"' is set in '/etc/apt/apt.conf.d/50unattended-upgrades'. In shell: $ uname -r 4.4.0-22-generic $ apt-get -s autoremove NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.4.0-21 linux-headers-4.4.0-21-generic linux-headers-4.4.0-22 linux-headers-4.4.0-22-generic linux-headers-4.4.0-31-generic linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-31-generic linux-image-extra-4.4.0-21-generic linux-image-extra-4.4.0-22-generic linux-image-extra-4.4.0-31-generic 0 upgraded, 0 newly installed, 11 to remove and 13 not upgraded. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.12~ubuntu16.04.1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 21 16:11:27 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2016-04-28 (114 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.kernel.postinst.d.apt-auto-removal: [modified] mtime.conffile..etc.kernel.postinst.d.apt-auto-removal: 2016-07-30T12:15:32.706300 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1615381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1615381] Re: apt-get autoremove may remove current kernel
But I do believe it's simply the wrong package being upgraded here. The new apt package removes the conffiles the old library version needs, so it doesn't protect anything, so we need to make sure that apt Breaks libapt-pkg6.0 (<< 1.6.15) [or Depends on >= 1.6.15, whatever ends up nicer). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1615381 Title: apt-get autoremove may remove current kernel Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt source package in Hirsute: Fix Released Bug description: [Impact] APT will try and fail to remove the currently running kernel, when booted into an older kernel that is not protected. May wreak some havoc if mixed with other operations to the point that apt goes weird and needs manual fixing up. [Test case] For the SRUs we have included an automated test case that starts with an empty autoremove config file, and then checks that the running kernel is protected at runtime. You can also test manually, but it's not necessary: - Install new kernel - Reboot into kernel not listed as protected in 01autoremove-kernels - Run autoremove [Where problems could occur] We may more easily run out of space in /boot. hirsute has new autoremoval code that runs completely at runtime; but that seems a bit large to SRU after only a few weeks in hirsute. Hence, we should protect the current kernel _in addition_ to the other kernels, just like unattended-upgrades and update-manager do. This increases the risk of filling up /boot compared to older apt versions, but is at the same level as unattended-upgrades and update-manager. [Original bug report] This may happen, if you boot one of the older kernels, that is not protected by /etc/apt/apt.conf.d/01autoremove-kernels Workaround: run /etc/kernel/postinst.d/apt-auto-removal during each boot (e.g. by using cron). Note: The workaround breaks autoremoving feature of new unneeded kernels in unattended-upgrades i.e. the setting 'Unattended-Upgrade::Remove-New-Unused-Dependencies "true"' (which is default in 16.04 unless 'Unattended-Upgrade::Remove-Unused-Dependencies "true"' is set in '/etc/apt/apt.conf.d/50unattended-upgrades'. In shell: $ uname -r 4.4.0-22-generic $ apt-get -s autoremove NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.4.0-21 linux-headers-4.4.0-21-generic linux-headers-4.4.0-22 linux-headers-4.4.0-22-generic linux-headers-4.4.0-31-generic linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-31-generic linux-image-extra-4.4.0-21-generic linux-image-extra-4.4.0-22-generic linux-image-extra-4.4.0-31-generic 0 upgraded, 0 newly installed, 11 to remove and 13 not upgraded. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.12~ubuntu16.04.1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 21 16:11:27 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2016-04-28 (114 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.kernel.postinst.d.apt-auto-removal: [modified] mtime.conffile..etc.kernel.postinst.d.apt-auto-removal: 2016-07-30T12:15:32.706300 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1615381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1615381] Re: apt-get autoremove may remove current kernel
Jarno, you do realize that you need to upgrade libapt-pkg6.0, not apt? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1615381 Title: apt-get autoremove may remove current kernel Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt source package in Hirsute: Fix Released Bug description: [Impact] APT will try and fail to remove the currently running kernel, when booted into an older kernel that is not protected. May wreak some havoc if mixed with other operations to the point that apt goes weird and needs manual fixing up. [Test case] For the SRUs we have included an automated test case that starts with an empty autoremove config file, and then checks that the running kernel is protected at runtime. You can also test manually, but it's not necessary: - Install new kernel - Reboot into kernel not listed as protected in 01autoremove-kernels - Run autoremove [Where problems could occur] We may more easily run out of space in /boot. hirsute has new autoremoval code that runs completely at runtime; but that seems a bit large to SRU after only a few weeks in hirsute. Hence, we should protect the current kernel _in addition_ to the other kernels, just like unattended-upgrades and update-manager do. This increases the risk of filling up /boot compared to older apt versions, but is at the same level as unattended-upgrades and update-manager. [Original bug report] This may happen, if you boot one of the older kernels, that is not protected by /etc/apt/apt.conf.d/01autoremove-kernels Workaround: run /etc/kernel/postinst.d/apt-auto-removal during each boot (e.g. by using cron). Note: The workaround breaks autoremoving feature of new unneeded kernels in unattended-upgrades i.e. the setting 'Unattended-Upgrade::Remove-New-Unused-Dependencies "true"' (which is default in 16.04 unless 'Unattended-Upgrade::Remove-Unused-Dependencies "true"' is set in '/etc/apt/apt.conf.d/50unattended-upgrades'. In shell: $ uname -r 4.4.0-22-generic $ apt-get -s autoremove NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.4.0-21 linux-headers-4.4.0-21-generic linux-headers-4.4.0-22 linux-headers-4.4.0-22-generic linux-headers-4.4.0-31-generic linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-31-generic linux-image-extra-4.4.0-21-generic linux-image-extra-4.4.0-22-generic linux-image-extra-4.4.0-31-generic 0 upgraded, 0 newly installed, 11 to remove and 13 not upgraded. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.12~ubuntu16.04.1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 21 16:11:27 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2016-04-28 (114 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.kernel.postinst.d.apt-auto-removal: [modified] mtime.conffile..etc.kernel.postinst.d.apt-auto-removal: 2016-07-30T12:15:32.706300 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1615381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1615381] Re: apt-get autoremove may remove current kernel
Thereafter I installed the proposed apt by $ sudo apt install apt -t=bionic-proposed $ apt --version apt 1.6.16 (i386) $ apt autoremove -s $ uname -r 5.4.0-121-generic $ apt autoremove -s NOTE: This is only a simulation! apt needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-5.4.0-121-generic linux-headers-5.4.0-122-generic linux-hwe-5.4-headers-5.4.0-121 linux-hwe-5.4-headers-5.4.0-122 linux-image-5.4.0-121-generic linux-image-5.4.0-122-generic linux-modules-5.4.0-121-generic linux-modules-5.4.0-122-generic linux-modules-extra-5.4.0-121-generic linux-modules-extra-5.4.0-122-generic 0 upgraded, 0 newly installed, 10 to remove and 0 not upgraded. Remv linux-headers-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-headers-5.4.0-122-generic [5.4.0-122.138~18.04.1] Remv linux-hwe-5.4-headers-5.4.0-121 [5.4.0-121.137~18.04.1] Remv linux-hwe-5.$ apt autoremove -s NOTE: This is only a simulation! apt needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-5.4.0-121-generic linux-headers-5.4.0-122-generic linux-hwe-5.4-headers-5.4.0-121 linux-hwe-5.4-headers-5.4.0-122 linux-image-5.4.0-121-generic linux-image-5.4.0-122-generic linux-modules-5.4.0-121-generic linux-modules-5.4.0-122-generic linux-modules-extra-5.4.0-121-generic linux-modules-extra-5.4.0-122-generic 0 upgraded, 0 newly installed, 10 to remove and 0 not upgraded. Remv linux-headers-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-headers-5.4.0-122-generic [5.4.0-122.138~18.04.1] Remv linux-hwe-5.4-headers-5.4.0-121 [5.4.0-121.137~18.04.1] Remv linux-hwe-5.4-headers-5.4.0-122 [5.4.0-122.138~18.04.1] Remv linux-modules-extra-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-image-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-modules-extra-5.4.0-122-generic [5.4.0-122.138~18.04.1] Remv linux-image-5.4.0-122-generic [5.4.0-122.138~18.04.1] Remv linux-modules-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-modules-5.4.0-122-generic [5.4.0-122.138~18.04.1] 4-headers-5.4.0-122 [5.4.0-122.138~18.04.1] Remv linux-modules-extra-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-image-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-modules-extra-5.4.0-122-generic [5.4.0-122.138~18.04.1] Remv linux-image-5.4.0-122-generic [5.4.0-122.138~18.04.1] Remv linux-modules-5.4.0-121-generic [5.4.0-121.137~18.04.1] Remv linux-modules-5.4.0-122-generic [5.4.0-122.138~18.04.1] So the proposed apt would have removed current kernel and this seems to be regression from version 1.6.14. ** Tags removed: verification-needed-bionic ** Tags added: verification-failed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1615381 Title: apt-get autoremove may remove current kernel Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt source package in Hirsute: Fix Released Bug description: [Impact] APT will try and fail to remove the currently running kernel, when booted into an older kernel that is not protected. May wreak some havoc if mixed with other operations to the point that apt goes weird and needs manual fixing up. [Test case] For the SRUs we have included an automated test case that starts with an empty autoremove config file, and then checks that the running kernel is protected at runtime. You can also test manually, but it's not necessary: - Install new kernel - Reboot into kernel not listed as protected in 01autoremove-kernels - Run autoremove [Where problems could occur] We may more easily run out of space in /boot. hirsute has new autoremoval code that runs completely at runtime; but that seems a bit large to SRU after only a few weeks in hirsute. Hence, we should protect the current kernel _in addition_ to the other kernels, just like unattended-upgrades and update-manager do. This increases the risk of filling up /boot compared to older apt versions, but is at the same level as un
[Touch-packages] [Bug 1983998] Re: USB sound card not detected
** Package changed: ubuntu => alsa-driver (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1983998 Title: USB sound card not detected Status in alsa-driver package in Ubuntu: New Bug description: usbc mics https://www.boya-mic.com/lavaliermicrophones/1430.html connects and immediately disconnects, ls usb hangs for a while, when usbc device is connected. it works on win laptop well. ``` [10877.622942] usb 3-4: new full-speed USB device number 28 using xhci_hcd [10877.779590] usb 3-4: New USB device found, idVendor=0c76, idProduct=153f, bcdDevice= 1.00 [10877.779596] usb 3-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [10877.779599] usb 3-4: Product: USB PnP Audio Device [10877.983589] usb 3-4: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10877.983593] usb 3-4: [51] FU [Mic Playback Volume] ch = 1, val = 0/7936/16 [10878.009593] usb 3-4: Warning! Unlikely big volume range (=1008), cval->res is probably wrong. [10878.009597] usb 3-4: [49] FU [Speaker Playback Volume] ch = 2, val = -16129/-1/16 [10878.035587] usb 3-4: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.035591] usb 3-4: [50] FU [Mic Capture Volume] ch = 1, val = 0/7936/16 [10878.038757] input: USB PnP Audio Device as /devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:06:00.3/usb3/3-4/3-4:1.3/0003:0C76:153F.001B/input/input45 [10878.095081] hid-generic 0003:0C76:153F.001B: input,hidraw6: USB HID v1.00 Device [USB PnP Audio Device] on usb-:06:00.3-4/input3 [10878.095179] usb 3-3: USB disconnect, device number 27 [10878.426945] usb 3-3: new full-speed USB device number 29 using xhci_hcd [10878.587590] usb 3-3: New USB device found, idVendor=0c76, idProduct=153f, bcdDevice= 1.00 [10878.587597] usb 3-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [10878.587599] usb 3-3: Product: USB PnP Audio Device [10878.783592] usb 3-3: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.783597] usb 3-3: [51] FU [Mic Playback Volume] ch = 1, val = 0/7936/16 [10878.809597] usb 3-3: Warning! Unlikely big volume range (=1008), cval->res is probably wrong. [10878.809601] usb 3-3: [49] FU [Speaker Playback Volume] ch = 2, val = -16129/-1/16 [10878.835592] usb 3-3: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.835596] usb 3-3: [50] FU [Mic Capture Volume] ch = 1, val = 0/7936/16 [10878.838754] input: USB PnP Audio Device as /devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:06:00.3/usb3/3-3/3-3:1.3/0003:0C76:153F.001C/input/input46 [10878.895092] hid-generic 0003:0C76:153F.001C: input,hidraw5: USB HID v1.00 Device [USB PnP Audio Device] on usb-:06:00.3-3/input3 [10878.895190] usb 3-4: USB disconnect, device number 28 ``` ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-45.48-generic 5.15.39 Uname: Linux 5.15.0-45-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: vany 12211 F pulseaudio /dev/snd/controlC0: vany 12211 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Aug 8 18:28:32 2022 InstallationDate: Installed on 2020-11-26 (619 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Title: USB sound card not detected UpgradeStatus: Upgraded to jammy on 2022-05-23 (76 days ago) dmi.bios.date: 04/01/2020 dmi.bios.release: 5.14 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1407 dmi.board.asset.tag: Default string dmi.board.name: TUF GAMING X570-PLUS (WI-FI) dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1407:bd04/01/2020:br5.14:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnTUFGAMINGX570-PLUS(WI-FI):rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1983998/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touc
[Touch-packages] [Bug 1983998] [NEW] USB sound card not detected
You have been subscribed to a public bug: usbc mics https://www.boya-mic.com/lavaliermicrophones/1430.html connects and immediately disconnects, ls usb hangs for a while, when usbc device is connected. it works on win laptop well. ``` [10877.622942] usb 3-4: new full-speed USB device number 28 using xhci_hcd [10877.779590] usb 3-4: New USB device found, idVendor=0c76, idProduct=153f, bcdDevice= 1.00 [10877.779596] usb 3-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [10877.779599] usb 3-4: Product: USB PnP Audio Device [10877.983589] usb 3-4: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10877.983593] usb 3-4: [51] FU [Mic Playback Volume] ch = 1, val = 0/7936/16 [10878.009593] usb 3-4: Warning! Unlikely big volume range (=1008), cval->res is probably wrong. [10878.009597] usb 3-4: [49] FU [Speaker Playback Volume] ch = 2, val = -16129/-1/16 [10878.035587] usb 3-4: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.035591] usb 3-4: [50] FU [Mic Capture Volume] ch = 1, val = 0/7936/16 [10878.038757] input: USB PnP Audio Device as /devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:06:00.3/usb3/3-4/3-4:1.3/0003:0C76:153F.001B/input/input45 [10878.095081] hid-generic 0003:0C76:153F.001B: input,hidraw6: USB HID v1.00 Device [USB PnP Audio Device] on usb-:06:00.3-4/input3 [10878.095179] usb 3-3: USB disconnect, device number 27 [10878.426945] usb 3-3: new full-speed USB device number 29 using xhci_hcd [10878.587590] usb 3-3: New USB device found, idVendor=0c76, idProduct=153f, bcdDevice= 1.00 [10878.587597] usb 3-3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [10878.587599] usb 3-3: Product: USB PnP Audio Device [10878.783592] usb 3-3: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.783597] usb 3-3: [51] FU [Mic Playback Volume] ch = 1, val = 0/7936/16 [10878.809597] usb 3-3: Warning! Unlikely big volume range (=1008), cval->res is probably wrong. [10878.809601] usb 3-3: [49] FU [Speaker Playback Volume] ch = 2, val = -16129/-1/16 [10878.835592] usb 3-3: Warning! Unlikely big volume range (=496), cval->res is probably wrong. [10878.835596] usb 3-3: [50] FU [Mic Capture Volume] ch = 1, val = 0/7936/16 [10878.838754] input: USB PnP Audio Device as /devices/pci:00/:00:01.2/:02:00.0/:03:08.0/:06:00.3/usb3/3-3/3-3:1.3/0003:0C76:153F.001C/input/input46 [10878.895092] hid-generic 0003:0C76:153F.001C: input,hidraw5: USB HID v1.00 Device [USB PnP Audio Device] on usb-:06:00.3-3/input3 [10878.895190] usb 3-4: USB disconnect, device number 28 ``` ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-45.48-generic 5.15.39 Uname: Linux 5.15.0-45-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: vany 12211 F pulseaudio /dev/snd/controlC0: vany 12211 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Aug 8 18:28:32 2022 InstallationDate: Installed on 2020-11-26 (619 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Title: USB sound card not detected UpgradeStatus: Upgraded to jammy on 2022-05-23 (76 days ago) dmi.bios.date: 04/01/2020 dmi.bios.release: 5.14 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1407 dmi.board.asset.tag: Default string dmi.board.name: TUF GAMING X570-PLUS (WI-FI) dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1407:bd04/01/2020:br5.14:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnTUFGAMINGX570-PLUS(WI-FI):rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- USB sound card not detected https://bugs.launchpad.net/bugs/1983998 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1615381] Re: apt-get autoremove may remove current kernel
For some reason the test case worked even with apt 1.6.14 as the following shows: $ apt policy apt apt: Installed: 1.6.14 Candidate: 1.6.14 Version table: 1.6.16 400 400 http://mirrors.nic.funet.fi/ubuntu bionic-proposed/main i386 Packages *** 1.6.14 500 500 http://mirrors.nic.funet.fi/ubuntu bionic-updates/main i386 Packages 100 /var/lib/dpkg/status 1.6.12ubuntu0.2 500 500 http://mirrors.nic.funet.fi/ubuntu bionic-security/main i386 Packages 1.6.1 500 500 http://mirrors.nic.funet.fi/ubuntu bionic/main i386 Packages $ grep '\^linux-image' /etc/apt/apt.conf.d/01autoremove-kernels "^linux-image-5\.4\.0-122-generic$"; "^linux-image-5\.4\.0-123-generic$"; "^linux-image-extra-5\.4\.0-122-generic$"; "^linux-image-extra-5\.4\.0-123-generic$"; "^linux-image-unsigned-5\.4\.0-122-generic$"; "^linux-image-unsigned-5\.4\.0-123-generic$"; $ uname -r 5.4.0-121-generic $ dpkg -l linux-image-5.4.0-121-generic Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-=-=== ii linux-image-5.4.0-121-generic 5.4.0-121.137~18.04.1 i386 Linux kernel image for version 5.4.0 on 32 bit x86 SMP $ apt-cache rdepends --installed --recurse linux-image-5.4.0-121-generic linux-image-5.4.0-121-generic Reverse Depends: |linux-modules-extra-5.4.0-121-generic linux-modules-extra-5.4.0-121-generic Reverse Depends: $ apt-mark showauto linux-image-5.4.0-121-generic linux-modules-extra-5.4.0-121-generic linux-image-5.4.0-121-generic linux-modules-extra-5.4.0-121-generic $ sudo apt autoremove Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1615381 Title: apt-get autoremove may remove current kernel Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt source package in Hirsute: Fix Released Bug description: [Impact] APT will try and fail to remove the currently running kernel, when booted into an older kernel that is not protected. May wreak some havoc if mixed with other operations to the point that apt goes weird and needs manual fixing up. [Test case] For the SRUs we have included an automated test case that starts with an empty autoremove config file, and then checks that the running kernel is protected at runtime. You can also test manually, but it's not necessary: - Install new kernel - Reboot into kernel not listed as protected in 01autoremove-kernels - Run autoremove [Where problems could occur] We may more easily run out of space in /boot. hirsute has new autoremoval code that runs completely at runtime; but that seems a bit large to SRU after only a few weeks in hirsute. Hence, we should protect the current kernel _in addition_ to the other kernels, just like unattended-upgrades and update-manager do. This increases the risk of filling up /boot compared to older apt versions, but is at the same level as unattended-upgrades and update-manager. [Original bug report] This may happen, if you boot one of the older kernels, that is not protected by /etc/apt/apt.conf.d/01autoremove-kernels Workaround: run /etc/kernel/postinst.d/apt-auto-removal during each boot (e.g. by using cron). Note: The workaround breaks autoremoving feature of new unneeded kernels in unattended-upgrades i.e. the setting 'Unattended-Upgrade::Remove-New-Unused-Dependencies "true"' (which is default in 16.04 unless 'Unattended-Upgrade::Remove-Unused-Dependencies "true"' is set in '/etc/apt/apt.conf.d/50unattended-upgrades'. In shell: $ uname -r 4.4.0-22-generic $ apt-get -s autoremove NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The fol
[Touch-packages] [Bug 1981622] Re: mtd device must be supplied (device name is empty)
I have the same issue on Ubuntu 22.04:
[4.528478] systemd[1]: Starting Load Kernel Module mtdpstore...
[4.533051] mtd device must be supplied (device name is empty)
[4.833395] mtd device must be supplied (device name is empty)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981622
Title:
mtd device must be supplied (device name is empty)
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Confirmed
Status in systemd source package in Jammy:
Confirmed
Bug description:
[WORKAROUND]
This will NOT fix a system that is not booting, because the "mtd
device must be supplied (device name is empty)" message is not the
cause of failed boots. This work around is only for those who are
annoyed by the error message, but are otherwise not experiencing any
issues.
If you are not able to boot your system, but you see this error
message, please open a separate bug with your journalctl and dmesg
logs.
# cp /{lib,etc}/systemd/system/systemd-pstore.service
# sed -i 's/modprobe@mtdpstore.service //'
/etc/systemd/system/systemd-pstore.service
# systemctl daemon-reload
[Impact]
Due to mtdpstore not being properly configured as a pstore backend,
when systemd-pstore.service tries to load the module, users get the
following error in dmesg:
[ 18.453473] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 18.462685] mtd device must be supplied (device name is empty)
This is a distracting error for users trying to diagnose other system
issues, especially if their system does not boot after a kernel crash
and this is the only message displayed on the console.
[Test Plan]
* Force a kernel crash to populate /sys/fs/pstore, thus causing
systemd-pstore.service to start on the subsequent boot:
# echo 1 > /proc/sys/kernel/sysrq
# echo 1 > /proc/sys/kernel/panic
# echo c > /proc/sysrq-trigger
* When the system reboots, observe the error in dmesg:
# dmesg | grep mtd
[Where problems could occur]
If a system was relying on this pstore backend, and mtdpstore is built
as a module, it is possible for systemd-pstore.service to trigger
before mtdpstore is loaded, causing systemd-pstore to not copy the
contents of /sys/fs/pstore. Note however that before the patched
introduced as a result of bug 1978079, systemd-pstore.service would
not attempt to load *any* kernel modules.
[Original Description]
After updating my 22.04 system (possibly caused by Systemd update).
And now booting, dmesg has two errors:
'mtd device must be supplied (device name is empty)'.
See line 8 and 134 in the included logfile.
The system are booting as it should though, and the system are working
like it should no errors at all.
Is this maybe caused by 'efi-pstore-not-cleared-on-boot.patch' in
systemd?
I have an EFI mounted at boot but it isn't used because I have
installed my system in legacy BIOS mode.
Is this maybe the culprit?
I could ignore the message but it isn't nice though.
Regards
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1981622/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983981] Re: Wrong package version displayed in action summary if update is available
Note for reader: The wrong version is in the list of packages to be removed. ** Changed in: apt (Ubuntu) Importance: Undecided => Low ** Changed in: apt (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1983981 Title: Wrong package version displayed in action summary if update is available Status in apt package in Ubuntu: Confirmed Bug description: If an update for a package is available but not installed, simulating a purge shows the wrong version. On that 20.04 system, an update to libxml2 2.9.10+dfsg-5ubuntu0.20.04.4 was available but only the ".3" one was installed. Simulating a purge gives this bogus output (with `APT::Get::Show-Versions "true"`): $ apt-get autopurge -s libxml2 NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libicu66* (66.1-2ubuntu2.1) libxml2* (2.9.10+dfsg-5ubuntu0.20.04.4) shared-mime-info* (1.15-1) 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Purg shared-mime-info [1.15-1] Purg libxml2 [2.9.10+dfsg-5ubuntu0.20.04.3] Purg libicu66 [66.1-2ubuntu2.1] In the above, the "REMOVED" section shows the wrong version number but the simulation part is OK. # Additional information Note: libxml2's update was applied before checking the policy. $ apt-cache policy apt libxml2 apt: Installed: 2.0.9 Candidate: 2.0.9 Version table: *** 2.0.9 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2ubuntu0.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 2.0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages libxml2: Installed: 2.9.10+dfsg-5ubuntu0.20.04.4 Candidate: 2.9.10+dfsg-5ubuntu0.20.04.4 Version table: *** 2.9.10+dfsg-5ubuntu0.20.04.4 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.9.10+dfsg-5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages $ lsb_release -sd Ubuntu 20.04.4 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1983981/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899156] Re: VPN through Network Manager GUI with Pulse Connect Secure host name problem
Having the same problem since the upgrade from Ubuntu 21.04 to Ubuntu 22.04.1 LTS. SSL vpn does not connect with certificate error (Server certificate verify failed: signer not found) followed by a 404. Tried selecting root intermediate & appliance cert via the vpn config (next to the option 'CA certificate) as well as adding them to the system to no avail. NetworkManager version 1.36.6 & openconnection version v8.20-1. Usig the CLI as a work around also works for me -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1899156 Title: VPN through Network Manager GUI with Pulse Connect Secure host name problem Status in network-manager package in Ubuntu: Confirmed Bug description: Release version: Ubuntu 20.04.1 LTS Version of network-manager-openconnect: 1.2.6-1 Version of openconnect: 8.05-1 VPN connection created through Network Manager GUI with VPN Protocol: Pulse Connect Secure converts gateway host name to IP when making a connection. It results in getting HTTP 404 error in NetworkManager.service logs because of failed SSL certificate validation. Screenshot attached. Gateway in Network Manager GUI is in URL format: https://xxx When using openconnect command: sudo openconnect --protocol=pulse https://xxx all works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1899156/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899156] Re: VPN through Network Manager GUI with Pulse Connect Secure host name problem
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: network-manager (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1899156 Title: VPN through Network Manager GUI with Pulse Connect Secure host name problem Status in network-manager package in Ubuntu: Confirmed Bug description: Release version: Ubuntu 20.04.1 LTS Version of network-manager-openconnect: 1.2.6-1 Version of openconnect: 8.05-1 VPN connection created through Network Manager GUI with VPN Protocol: Pulse Connect Secure converts gateway host name to IP when making a connection. It results in getting HTTP 404 error in NetworkManager.service logs because of failed SSL certificate validation. Screenshot attached. Gateway in Network Manager GUI is in URL format: https://xxx When using openconnect command: sudo openconnect --protocol=pulse https://xxx all works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1899156/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1954716] Re: rpi nfsroot vers=4 not supported anymore?
Thanks, I’ll look at that. I note that this issue is now a confirmed bug. What does that mean in practical terms? Will it be dealt with this week, this month, this year…? I need to be able to boot from NFSv4. If RaspiOS can do that it might make sense for me to move after 15 years from Ubuntu to RaspiOS. I don’t want to, but I’ve already wasted months on this issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1954716 Title: rpi nfsroot vers=4 not supported anymore? Status in klibc package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Invalid Bug description: I'm running `5.13.0-1011-raspi #13-Ubuntu SMP PREEMPT Fri Nov 19 18:40:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux` and have successfully set up netbooting on my RPi 4B (4GB). When I do not specify a `vers=` in cmdline.txt, NFS version 3 is used. I'd like to move to version 4, but unlike the setup described in https://forums.raspberrypi.com/viewtopic.php?p=1751741#p1751741, I cannot get `vers=4` (or any sub-version to work): the console logs `invalid value for vers.` for whatever I try. Current working cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp ro ip=dhcp rootwait fixrtc splash ``` Nonworking cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp,vers=4 ro ip=dhcp rootwait fixrtc splash ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1954716/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
Regarding zlib focal-proposed migration:
For libbio-samtools-perl it's the same situation like on kinetic.
samtools-legacy requires the PR #1258, and libbio-samtools-perl a rebuild (to
link against the new libbio-dev). See update-excuse bug LP#1983255.
On top vcftools misses the 'Remove compressBound assertions' (PR #1258) fix as
well.
I created a separate update-execuse bug LP#1983867.
The mentioned issue with htslib/1.10.2-3 is because the patched htslib
1.10.2-3ubuntu0.1 (that again incl. PR #1258) is needed:
https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#htslib
This htslib 1.10.2-3ubuntu0.1 will at least solve kallisto, libtabixpp
and probably samtools as well.
The isues with the kernels linux-hwe-5.11, linux-hwe-5.13 and linux-
hwe-5.15 are all time outs on arm64, resspectively amrhf builds. So it's
worth to retrigger these.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Committed
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
New
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
New
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, &dest_len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
[Touch-packages] [Bug 1979313] Re: kubeadm doesn't work with containerd version of apt install
Thanks Fabian, creating a containerd config and putting `SystemdCgroup = true` there did fix it for me By the way, how did you manage to find the cause of this issue? I want to have the same debugging skills as you do. ** Also affects: containerd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1979313 Title: kubeadm doesn't work with containerd version of apt install Status in apt package in Ubuntu: Confirmed Status in containerd package in Ubuntu: New Bug description: Version of Ubuntu: Description:Ubuntu 22.04 LTS Release:22.04 kubeadm: Installed: 1.24.2-00 Candidate: 1.24.2-00 Package that has the problem: containerd: Installed: 1.5.9-0ubuntu3 Candidate: 1.5.9-0ubuntu3 Version table: *** 1.5.9-0ubuntu3 500 500 http://ro.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status Problem: Kubeadm is not compatibile with this version of containerd that is installed by `apt install containerd`. If I use `kubeadm init` it will create a cluster which instead of staying alive will die after a couple of minutes. The problem is in the config file of containerd, which has the following parameter set to false: `SystemdCgroup = false` Solution: To solve this, the containerd config parameter SystemdCgroup needs to be set to true. It is set to true in the containerd v1.6.2, but by default, apt installs the version v1.5.9, which worked on Ubuntu 20.04 but does not work for Ubuntu 22.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1979313/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979313] Re: kubeadm doesn't work with containerd version of apt install
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: apt (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1979313 Title: kubeadm doesn't work with containerd version of apt install Status in apt package in Ubuntu: Confirmed Status in containerd package in Ubuntu: New Bug description: Version of Ubuntu: Description:Ubuntu 22.04 LTS Release:22.04 kubeadm: Installed: 1.24.2-00 Candidate: 1.24.2-00 Package that has the problem: containerd: Installed: 1.5.9-0ubuntu3 Candidate: 1.5.9-0ubuntu3 Version table: *** 1.5.9-0ubuntu3 500 500 http://ro.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status Problem: Kubeadm is not compatibile with this version of containerd that is installed by `apt install containerd`. If I use `kubeadm init` it will create a cluster which instead of staying alive will die after a couple of minutes. The problem is in the config file of containerd, which has the following parameter set to false: `SystemdCgroup = false` Solution: To solve this, the containerd config parameter SystemdCgroup needs to be set to true. It is set to true in the containerd v1.6.2, but by default, apt installs the version v1.5.9, which worked on Ubuntu 20.04 but does not work for Ubuntu 22.04. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1979313/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983981] [NEW] Wrong package version displayed in action summary if update is available
Public bug reported: If an update for a package is available but not installed, simulating a purge shows the wrong version. On that 20.04 system, an update to libxml2 2.9.10+dfsg-5ubuntu0.20.04.4 was available but only the ".3" one was installed. Simulating a purge gives this bogus output (with `APT::Get::Show-Versions "true"`): $ apt-get autopurge -s libxml2 NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libicu66* (66.1-2ubuntu2.1) libxml2* (2.9.10+dfsg-5ubuntu0.20.04.4) shared-mime-info* (1.15-1) 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Purg shared-mime-info [1.15-1] Purg libxml2 [2.9.10+dfsg-5ubuntu0.20.04.3] Purg libicu66 [66.1-2ubuntu2.1] In the above, the "REMOVED" section shows the wrong version number but the simulation part is OK. # Additional information Note: libxml2's update was applied before checking the policy. $ apt-cache policy apt libxml2 apt: Installed: 2.0.9 Candidate: 2.0.9 Version table: *** 2.0.9 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2ubuntu0.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 2.0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages libxml2: Installed: 2.9.10+dfsg-5ubuntu0.20.04.4 Candidate: 2.9.10+dfsg-5ubuntu0.20.04.4 Version table: *** 2.9.10+dfsg-5ubuntu0.20.04.4 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.9.10+dfsg-5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages $ lsb_release -sd Ubuntu 20.04.4 LTS ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1983981 Title: Wrong package version displayed in action summary if update is available Status in apt package in Ubuntu: New Bug description: If an update for a package is available but not installed, simulating a purge shows the wrong version. On that 20.04 system, an update to libxml2 2.9.10+dfsg-5ubuntu0.20.04.4 was available but only the ".3" one was installed. Simulating a purge gives this bogus output (with `APT::Get::Show-Versions "true"`): $ apt-get autopurge -s libxml2 NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: libicu66* (66.1-2ubuntu2.1) libxml2* (2.9.10+dfsg-5ubuntu0.20.04.4) shared-mime-info* (1.15-1) 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. Purg shared-mime-info [1.15-1] Purg libxml2 [2.9.10+dfsg-5ubuntu0.20.04.3] Purg libicu66 [66.1-2ubuntu2.1] In the above, the "REMOVED" section shows the wrong version number but the simulation part is OK. # Additional information Note: libxml2's update was applied before checking the policy. $ apt-cache policy apt libxml2 apt: Installed: 2.0.9 Candidate: 2.0.9 Version table: *** 2.0.9 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2ubuntu0.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 2.0.2 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages libxml2: Installed: 2.9.10+dfsg-5ubuntu0.20.04.4 Candidate: 2.9.10+dfsg-5ubuntu0.20.04.4 Version table: *** 2.9.10+dfsg-5ubuntu0.20.04.4 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.9.10+dfsg-5 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages $ lsb_release -sd Ubuntu 20.04.4 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1983981/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1853638] Re: BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet device seems to be dropping data
I am having the same issue. Unfortunately the systems are already in production so testing is a bit limited and the issue was not present at first (not sure why or we didn't notice somehow). I can confirm that I am seeing approx. 8% loss and huge latency > 1s sometimes. Both tested with Ubuntu 18.04 and Ubuntu 20.04 with standard kernel and Libvirt/Openstack VMs. No difference. Bond with LACP, bond first NIC primary and bond second NIC primary makes absolutely no difference. Changed almost all NIC parameters (offloading, ring size, queues) etc., still same result. My last bet was to completely remove the bond and just use the first NIC interface. That worked and now I have stable latency and no loss. Don't know what exactly causes this because we already replaced the NIC with Mellanox and even had the same issue, so I am not sure if this is an issue that happens when the BCM NIC is present but NOT USED somehow (was installed on mainboard). But I can't do further testing now. Removing the bond was my solution as @niveditasinghvi solution did not work for me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1853638 Title: BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet device seems to be dropping data Status in linux package in Ubuntu: Confirmed Status in network-manager package in Ubuntu: Confirmed Bug description: The issue appears to be with the BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet device seems to be dropping data Basically, we are dropping data, as you can see from the benchmark tool as follows: tcdforge@x310a:/usr/local/lib/lib/uhd/examples$ ./benchmark_rate --rx_rate 10e6 --tx_rate 10e6 --duration 300 [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.14.1.1-0-g98c7c986 [WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam [00:00:00.07] Creating the usrp device with: ... [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 1472 bytes. [INFO] [X300] Radio 1x clock: 200 MHz [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1308 MB/s) [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1316 MB/s) [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001) [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001) [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0) [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0) [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0) Using Device: Single USRP: Device: X-Series Device Mboard 0: X310 RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: SBX-120 RX RX Channel: 1 RX DSP: 0 RX Dboard: B RX Subdev: SBX-120 RX TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: SBX-120 TX TX Channel: 1 TX DSP: 0 TX Dboard: B TX Subdev: SBX-120 TX [00:00:04.305374] Setting device timestamp to 0... [WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam [00:00:04.310990] Testing receive rate 10.00 Msps on 1 channels [WARNING] [UHD] Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam [00:00:04.318356] Testing transmit rate 10.00 Msps on 1 channels [00:00:06.693119] Detected Rx sequence error. D[00:00:09.402843] Detected Rx sequence error. DD[00:00:40.927978] Detected Rx sequence error. D[00:01:44.982243] Detected Rx sequence error. D[00:02:11.400692] Detected Rx sequence error. D[00:02:14.805292] Detected Rx sequence error. D[00:02:41.875596] Detected Rx sequence error. D[00:03:06.927743] Detected Rx sequence error. D[00:03:47.967891] Detected Rx sequence error. D[00:03:58.233659] Detected Rx sequence error. D[00:03:58.876588] Detected Rx sequence error. D[00:04:03.139770] Detected Rx sequence error. D[00:04:45.287465] Detected Rx sequence error. D[00:04:56.425845] Detected Rx sequence error. D[00:04:57.929209] Detected Rx sequence error. [00:05:04.529548] Benchmark complete. Benchmark rate summary: Num received samples: 2995435936 Num dropped samples: 4622800 Num overruns detect
[Touch-packages] [Bug 1954716] Re: rpi nfsroot vers=4 not supported anymore?
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409272#14 for a work-around which replaces nfsmount in the initrd with /sbin/mount.nfs. But that probably pulls in dependencies and blows up the size of the initrd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1954716 Title: rpi nfsroot vers=4 not supported anymore? Status in klibc package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Invalid Bug description: I'm running `5.13.0-1011-raspi #13-Ubuntu SMP PREEMPT Fri Nov 19 18:40:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux` and have successfully set up netbooting on my RPi 4B (4GB). When I do not specify a `vers=` in cmdline.txt, NFS version 3 is used. I'd like to move to version 4, but unlike the setup described in https://forums.raspberrypi.com/viewtopic.php?p=1751741#p1751741, I cannot get `vers=4` (or any sub-version to work): the console logs `invalid value for vers.` for whatever I try. Current working cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp ro ip=dhcp rootwait fixrtc splash ``` Nonworking cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp,vers=4 ro ip=dhcp rootwait fixrtc splash ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1954716/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1954716] Re: rpi nfsroot vers=4 not supported anymore?
Debian 11 is also broken if an intird is being used but Raspberry Pi OS is *not* using an initrd hence not using nfsmount. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1954716 Title: rpi nfsroot vers=4 not supported anymore? Status in klibc package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Invalid Bug description: I'm running `5.13.0-1011-raspi #13-Ubuntu SMP PREEMPT Fri Nov 19 18:40:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux` and have successfully set up netbooting on my RPi 4B (4GB). When I do not specify a `vers=` in cmdline.txt, NFS version 3 is used. I'd like to move to version 4, but unlike the setup described in https://forums.raspberrypi.com/viewtopic.php?p=1751741#p1751741, I cannot get `vers=4` (or any sub-version to work): the console logs `invalid value for vers.` for whatever I try. Current working cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp ro ip=dhcp rootwait fixrtc splash ``` Nonworking cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp,vers=4 ro ip=dhcp rootwait fixrtc splash ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1954716/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974456] Re: regression: apt.postint fails if never previously configured
Verified. For bionic I ran mmdebstrap -v --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --aptopt='Acquire::http::proxy "http://localhost:8000/";;' bionic bionic- proposed http://archive.ubuntu.com/ubuntu 'deb http://archive.ubuntu.com/ubuntu/ bionic-proposed main' to enable proposed and this succeeded with Setting up apt (1.6.16) ... ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1974456 Title: regression: apt.postint fails if never previously configured Status in apt package in Ubuntu: Confirmed Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Bug description: [Impact] bootstrapping a system with apt that fixes #1968154 fails in focal and bionic, as they try to execute the config file that is being removed. This is not a problem on updates, only on new installs, so impact is limited to bootstrapping tools that enable -updates, such as mmdebstrap. [Test case] bootstrapping with -updates enabled can easily be tested with mmdebstrap: mmdebstrap -v focal ~/Projects/Ubuntu/Scratch/focal for example, on focal: Setting up apt (2.0.8) ... /var/lib/dpkg/info/apt.postinst: 65: /etc/kernel/postinst.d/apt-auto-removal: not found dpkg: error processing package apt (--configure): installed apt package post-installation script subprocess returned error exit status 127 [Regression potential] We remove 5 lines from the shell postinst script, there could be syntax errors? But then we'd see those during upgrades, so practically none. [Original bug report] #1968154 removed `/etc/kernel/postinst.d/apt-auto-removal` in this patch: https://git.launchpad.net/ubuntu/+source/apt/commit/?id=f9d2d993687c0d5223c241956ef6a0aabcf15bf0 ...but `apt.postinst` still tries to run it: # create kernel autoremoval blacklist on update if dpkg --compare-versions "$2" lt 0.9.9.3; then /etc/kernel/postinst.d/apt-auto-removal fi If I understand correctly, "$2" is the most-recently-configured- version, and if it's empty `dpkg --compare-versions lt` will evaluate to true. This fails when I'm building a focal (20.04) userspace from scratch: $ dpkg --configure -a [...] Setting up apt (2.0.8) ... /var/lib/dpkg/info/apt.postinst: 65: /etc/kernel/postinst.d/apt-auto-removal: not found dpkg: error processing package apt (--configure): installed apt package post-installation script subprocess returned error exit status 127 It works with apt 2.0.6. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1974456/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1954716] Re: rpi nfsroot vers=4 not supported anymore?
The upstream bug is in Debian 11. The current version of RaspiOS, which seems to support booting from NFSv4, is a Debian 11 derivative. That means that RaspiOS has fixed it for Debian 11. Is it possible to copy the RaspiOS solution? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1954716 Title: rpi nfsroot vers=4 not supported anymore? Status in klibc package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Invalid Bug description: I'm running `5.13.0-1011-raspi #13-Ubuntu SMP PREEMPT Fri Nov 19 18:40:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux` and have successfully set up netbooting on my RPi 4B (4GB). When I do not specify a `vers=` in cmdline.txt, NFS version 3 is used. I'd like to move to version 4, but unlike the setup described in https://forums.raspberrypi.com/viewtopic.php?p=1751741#p1751741, I cannot get `vers=4` (or any sub-version to work): the console logs `invalid value for vers.` for whatever I try. Current working cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp ro ip=dhcp rootwait fixrtc splash ``` Nonworking cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp,vers=4 ro ip=dhcp rootwait fixrtc splash ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1954716/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983859] [NEW] tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04
Public bug reported: When upgrading Ubuntu Desktop from 20.04 to 22.04, there's often (pretty much always) a crash from tracker-extract, as described in the following error report: https://errors.ubuntu.com/oops/d7866d85-14cc-11ed-a52b-fa163e55efd0 The crash occurs during the upgrade, which means it's fairly hard to investigate exactly what's going on as apport fails to extract a stack trace, the binaries being overwritten during the upgrade. However, the crash occurs because of a unhandled SIGSYS, meaning a seccomp filter issue. I've tried backporting this patch fixing a similar issue: https://gitlab.gnome.org/GNOME/tracker- miners/-/commit/4cda983b02e49f6bd28b94a6b96c9fe7026887ef but it doesn't apply, likely due to the code having diverged too much since. My proposal is thus to disable tracker-extract during upgrade, including in all user sessions. I'm assuming that the new version will be enabled automatically as its unit file changed name anyway. ** Affects: tracker (Ubuntu) Importance: High Status: Confirmed ** Affects: ubuntu-release-upgrader (Ubuntu) Importance: High Status: Confirmed ** Tags: fr-2595 ** Also affects: ubuntu-release-upgrader (Ubuntu) Importance: Undecided Status: New ** Changed in: ubuntu-release-upgrader (Ubuntu) Status: New => Confirmed ** Changed in: ubuntu-release-upgrader (Ubuntu) Importance: Undecided => High ** Tags added: fr-2595 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tracker in Ubuntu. https://bugs.launchpad.net/bugs/1983859 Title: tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04 Status in tracker package in Ubuntu: Confirmed Status in ubuntu-release-upgrader package in Ubuntu: Confirmed Bug description: When upgrading Ubuntu Desktop from 20.04 to 22.04, there's often (pretty much always) a crash from tracker-extract, as described in the following error report: https://errors.ubuntu.com/oops/d7866d85-14cc-11ed-a52b-fa163e55efd0 The crash occurs during the upgrade, which means it's fairly hard to investigate exactly what's going on as apport fails to extract a stack trace, the binaries being overwritten during the upgrade. However, the crash occurs because of a unhandled SIGSYS, meaning a seccomp filter issue. I've tried backporting this patch fixing a similar issue: https://gitlab.gnome.org/GNOME/tracker- miners/-/commit/4cda983b02e49f6bd28b94a6b96c9fe7026887ef but it doesn't apply, likely due to the code having diverged too much since. My proposal is thus to disable tracker-extract during upgrade, including in all user sessions. I'm assuming that the new version will be enabled automatically as its unit file changed name anyway. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1983859/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982898] Re: CVE-2021-46829: Buffer overwrite in io-gif-animation.c composite_frame() in gdk-pixbuf
This bug was fixed in the package gdk-pixbuf - 2.40.0+dfsg-3ubuntu0.3 --- gdk-pixbuf (2.40.0+dfsg-3ubuntu0.3) focal-security; urgency=medium * SECURITY UPDATE: Buffer overwrite in io-gif-animation.c composite_frame() (LP: #1982898) - debian/patches/CVE-2021-46829.patch: gif: Check for overflow when compositing or clearing frames. - CVE-2021-46829 -- Joshua Peisach Tue, 26 Jul 2022 20:42:00 -0400 ** Changed in: gdk-pixbuf (Ubuntu Focal) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdk-pixbuf in Ubuntu. https://bugs.launchpad.net/bugs/1982898 Title: CVE-2021-46829: Buffer overwrite in io-gif-animation.c composite_frame() in gdk-pixbuf Status in gdk-pixbuf package in Ubuntu: In Progress Status in gdk-pixbuf source package in Focal: Fix Released Bug description: [Impact] * A buffer overwrite exists in gdk-pixbuf's thumbnailer. * The GIF loader runs out of memory with specifically crafted files with bad frame data (and images with its sizes) over the integer limit. * After gdk-pixbuf-thum runs out of memory, other apps can and on low RAM systems like my old iMac, the system can completely run out of memory. * Or, in other ways, bad gif files in other applications can open the door for exploits. * Any app using gdk-pixbuf is affected, mainly file managers and image viewers. [Test Plan] * Take the POC's - they can be found in the issue in the GNOME repo * Open them in an application that uses gdk-pixbuf. I have managed to produce reactions with: - Nautilus, GNOME's file manager - Nemo, Cinnamon's file manager - Thunar, XFCE's file manager, which has its own thumbnailere (tumbler) that also inevitably fails and crashes - PCManFM, LXDE's file manager which straight up crashes - Caja, MATE's file manager causes libpixbufloader-gif to segfault (app still usable, no memory issues) - Eye of GNOME (eog) triggers the segfault in syslog - Eye of MATE (eom) segfaults * If you or the system couldn't tell something is wrong, cat /var/log/syslog and enjoy the segfaults or out of memory warnings or even kernel spam. [Where problems could occur] * The patch itself is simple, but since gdk-pixbuf is often used with GTK apps a mistake here could be problematic. * It is possible, and has happened in the past (which has been patched) that other bad GIFs can cause other crashes. * That patch is essentially overflow checks - changes with GLib (GNOME's, not to be confused with glibc) and the functions used in not only the patch but all of gdk-pixbuf can cause problems * Other failures to properly handle GIFs and broken or intentionally tampered GIFs can continue and always will open the door for security holes for other bugs * Again, overall a simple patch but as long as the GIFs remain handled properly, and no changes to the GLib functions are made and to other apps that use gdk-pixbuf (and assuming are not affected by the change and still work), the patch does not have much regression potential. [Other Info] * Besides Buffer overwrite/overflow issues, as aforementioned out of memory errors can happen. * Files attached are examples or crashes * Again, all apps using gdk-pixbuf are affected * https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/121/ * https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/190 * https://github.com/pedrib/PoC/blob/master/fuzzing/CVE-2021-46829/CVE-2021-46829.md ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: libgdk-pixbuf2.0-0 2.40.0+dfsg-3ubuntu0.2 ProcVersionSignature: Ubuntu 5.15.0-43.46~20.04.1-generic 5.15.39 Uname: Linux 5.15.0-43-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.24 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: X-Cinnamon Date: Tue Jul 26 19:33:41 2022 InstallationDate: Installed on 2021-11-24 (244 days ago) InstallationMedia: ubuntucinnamonremix "@BASECODENAME" (20210826) SourcePackage: gdk-pixbuf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1982898/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1954716] Re: rpi nfsroot vers=4 not supported anymore?
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: klibc (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1954716 Title: rpi nfsroot vers=4 not supported anymore? Status in klibc package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Invalid Bug description: I'm running `5.13.0-1011-raspi #13-Ubuntu SMP PREEMPT Fri Nov 19 18:40:23 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux` and have successfully set up netbooting on my RPi 4B (4GB). When I do not specify a `vers=` in cmdline.txt, NFS version 3 is used. I'd like to move to version 4, but unlike the setup described in https://forums.raspberrypi.com/viewtopic.php?p=1751741#p1751741, I cannot get `vers=4` (or any sub-version to work): the console logs `invalid value for vers.` for whatever I try. Current working cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp ro ip=dhcp rootwait fixrtc splash ``` Nonworking cmdline.txt: ``` dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.3.101:/srv/pinet/root,tcp,vers=4 ro ip=dhcp rootwait fixrtc splash ``` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1954716/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1615381] Re: apt-get autoremove may remove current kernel
Hello Jarno, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.16 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apt (Ubuntu Bionic) Status: Fix Released => Fix Committed ** Tags removed: verification-done verification-done-bionic ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1615381 Title: apt-get autoremove may remove current kernel Status in apt package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Trusty: Won't Fix Status in unattended-upgrades source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt source package in Hirsute: Fix Released Bug description: [Impact] APT will try and fail to remove the currently running kernel, when booted into an older kernel that is not protected. May wreak some havoc if mixed with other operations to the point that apt goes weird and needs manual fixing up. [Test case] For the SRUs we have included an automated test case that starts with an empty autoremove config file, and then checks that the running kernel is protected at runtime. You can also test manually, but it's not necessary: - Install new kernel - Reboot into kernel not listed as protected in 01autoremove-kernels - Run autoremove [Where problems could occur] We may more easily run out of space in /boot. hirsute has new autoremoval code that runs completely at runtime; but that seems a bit large to SRU after only a few weeks in hirsute. Hence, we should protect the current kernel _in addition_ to the other kernels, just like unattended-upgrades and update-manager do. This increases the risk of filling up /boot compared to older apt versions, but is at the same level as unattended-upgrades and update-manager. [Original bug report] This may happen, if you boot one of the older kernels, that is not protected by /etc/apt/apt.conf.d/01autoremove-kernels Workaround: run /etc/kernel/postinst.d/apt-auto-removal during each boot (e.g. by using cron). Note: The workaround breaks autoremoving feature of new unneeded kernels in unattended-upgrades i.e. the setting 'Unattended-Upgrade::Remove-New-Unused-Dependencies "true"' (which is default in 16.04 unless 'Unattended-Upgrade::Remove-Unused-Dependencies "true"' is set in '/etc/apt/apt.conf.d/50unattended-upgrades'. In shell: $ uname -r 4.4.0-22-generic $ apt-get -s autoremove NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-headers-4.4.0-21 linux-headers-4.4.0-21-generic linux-headers-4.4.0-22 linux-headers-4.4.0-22-generic linux-headers-4.4.0-31-generic linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic linux-image-4.4.0-31-generic linux-image-extra-4.4.0-21-generic linux-image-extra-4.4.0-22-generic linux-image-extra-4.4.0-31-generic 0 upgraded, 0 newly installed, 11 to remove and 13 not upgraded. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.12~ubuntu16.04.1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 A
[Touch-packages] [Bug 1968154] Please test proposed package
Hello Julian, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.16 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1968154 Title: Only keep 2 kernels Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Impish: Fix Released Bug description: [Impact] APT currently keeps 3 kernels or even 4 in some releases. Our boot partition is sized for a steady state of 2 kernels + 1 new one being unpacked, hence users run out of space and new kernels fail to install, upgrade runs might abort in the middle. It's not nice. [Test plan] 1. Have two kernels installed (let's call them version 3, 2) 2. Check that both kernels are not autoremovable 3. Install an old kernel (let's call it 1), and mark it automatic 4. Check that 1 will be autoremovable (apt autoremove -s) 5. Reboot into 1, check that 2 is autoremovable (apt autoremove -s) 6. Actually remove 2 7. Reboot into 3 and check that both 1 and 3 are now not autoremovable [Where problems could occur] We could keep the wrong kernels installed that the user did not expect. We remove the requirement to keep the most recently installed version, previously recorded in APT::LastInstalledKernel, to achieve this, as we had 3 hard requirements so far: 1. keep booted kernel 2. keep highest version 3. keep most recently installed 1 can't be removed as it would break running systems, 2 is what you definitely want to keep. During normal system lifetime, the most recently installed kernel is the same as the highest version, so 2==3, and there are no changes to behavior. Likewise, if you most recently installed an older kernel manually for debugging, it would be manually installed and not subject to removal, even if the rule is dropped. The behavior really only changes if you install an older kernel, and then mark it auto - that older kernel becomes automatically removable immediately after it is marked as auto. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1968154/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1974456] Re: regression: apt.postint fails if never previously configured
Hello David, or anyone else affected, Accepted apt into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apt/1.6.16 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: apt (Ubuntu Bionic) Status: Confirmed => Fix Committed ** Tags removed: verification-done ** Tags added: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1974456 Title: regression: apt.postint fails if never previously configured Status in apt package in Ubuntu: Confirmed Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Bug description: [Impact] bootstrapping a system with apt that fixes #1968154 fails in focal and bionic, as they try to execute the config file that is being removed. This is not a problem on updates, only on new installs, so impact is limited to bootstrapping tools that enable -updates, such as mmdebstrap. [Test case] bootstrapping with -updates enabled can easily be tested with mmdebstrap: mmdebstrap -v focal ~/Projects/Ubuntu/Scratch/focal for example, on focal: Setting up apt (2.0.8) ... /var/lib/dpkg/info/apt.postinst: 65: /etc/kernel/postinst.d/apt-auto-removal: not found dpkg: error processing package apt (--configure): installed apt package post-installation script subprocess returned error exit status 127 [Regression potential] We remove 5 lines from the shell postinst script, there could be syntax errors? But then we'd see those during upgrades, so practically none. [Original bug report] #1968154 removed `/etc/kernel/postinst.d/apt-auto-removal` in this patch: https://git.launchpad.net/ubuntu/+source/apt/commit/?id=f9d2d993687c0d5223c241956ef6a0aabcf15bf0 ...but `apt.postinst` still tries to run it: # create kernel autoremoval blacklist on update if dpkg --compare-versions "$2" lt 0.9.9.3; then /etc/kernel/postinst.d/apt-auto-removal fi If I understand correctly, "$2" is the most-recently-configured- version, and if it's empty `dpkg --compare-versions lt` will evaluate to true. This fails when I'm building a focal (20.04) userspace from scratch: $ dpkg --configure -a [...] Setting up apt (2.0.8) ... /var/lib/dpkg/info/apt.postinst: 65: /etc/kernel/postinst.d/apt-auto-removal: not found dpkg: error processing package apt (--configure): installed apt package post-installation script subprocess returned error exit status 127 It works with apt 2.0.6. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1974456/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983815] Re: no detection of the hdmi display moinitor
Thanks for the bug report. This may be caused by: * The Intel kernel graphics crash mentioned in CurrentDmesg.txt * An Nvidia driver problem (if the HDMI port is wired to the Nvidia GPU) * Something else Firstly, to see if we can stop the Intel graphics crash from happening please try adding this to /etc/environment: MUTTER_DEBUG_ENABLE_ATOMIC_KMS=0 and then reboot. ** Package changed: xorg (Ubuntu) => linux (Ubuntu) ** Also affects: nvidia-graphics-drivers-515 (Ubuntu) Importance: Undecided Status: New ** Tags added: hyb i915 nvidia rid ** Tags removed: hyb rid ** Tags added: hybrid ** Changed in: linux (Ubuntu) Status: New => Incomplete ** Changed in: nvidia-graphics-drivers-515 (Ubuntu) Status: New => Incomplete ** Tags added: multimonitor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1983815 Title: no detection of the hdmi display moinitor Status in linux package in Ubuntu: Incomplete Status in nvidia-graphics-drivers-515 package in Ubuntu: Incomplete Bug description: In the windows, hdmi display monitor work. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-43.46-generic 5.15.39 Uname: Linux 5.15.0-43-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file. .proc.driver.nvidia.gpus..03.00.0: Error: path was not a regular file. .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 515.65.01 Wed Jul 20 14:00:58 UTC 2022 GCC version: ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 8 16:27:14 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:22e9] Subsystem: Lenovo Device [17aa:22e9] InstallationDate: Installed on 2022-08-07 (1 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: LENOVO 21BVCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-43-generic root=UUID=240545ce-be3b-4291-87da-1fe7a719dca4 ro text SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/07/2022 dmi.bios.release: 1.24 dmi.bios.vendor: LENOVO dmi.bios.version: N3BET46W (1.24 ) dmi.board.asset.tag: Not Available dmi.board.name: 21BVCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0T76530 WIN dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.12 dmi.modalias: dmi:bvnLENOVO:bvrN3BET46W(1.24):bd06/07/2022:br1.24:efr1.12:svnLENOVO:pn21BVCTO1WW:pvrThinkPadT16Gen1:rvnLENOVO:rn21BVCTO1WW:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21BV_BU_Think_FM_ThinkPadT16Gen1: dmi.product.family: ThinkPad T16 Gen 1 dmi.product.name: 21BVCTO1WW dmi.product.sku: LENOVO_MT_21BV_BU_Think_FM_ThinkPad T16 Gen 1 dmi.product.version: ThinkPad T16 Gen 1 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.5-0ubuntu0.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1983815/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1983815] [NEW] no detection of the hdmi display moinitor
Public bug reported: In the windows, hdmi display monitor work. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-43.46-generic 5.15.39 Uname: Linux 5.15.0-43-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file. .proc.driver.nvidia.gpus..03.00.0: Error: path was not a regular file. .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 515.65.01 Wed Jul 20 14:00:58 UTC 2022 GCC version: ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 8 16:27:14 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:22e9] Subsystem: Lenovo Device [17aa:22e9] InstallationDate: Installed on 2022-08-07 (1 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: LENOVO 21BVCTO1WW ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-43-generic root=UUID=240545ce-be3b-4291-87da-1fe7a719dca4 ro text SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/07/2022 dmi.bios.release: 1.24 dmi.bios.vendor: LENOVO dmi.bios.version: N3BET46W (1.24 ) dmi.board.asset.tag: Not Available dmi.board.name: 21BVCTO1WW dmi.board.vendor: LENOVO dmi.board.version: SDK0T76530 WIN dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.12 dmi.modalias: dmi:bvnLENOVO:bvrN3BET46W(1.24):bd06/07/2022:br1.24:efr1.12:svnLENOVO:pn21BVCTO1WW:pvrThinkPadT16Gen1:rvnLENOVO:rn21BVCTO1WW:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21BV_BU_Think_FM_ThinkPadT16Gen1: dmi.product.family: ThinkPad T16 Gen 1 dmi.product.name: 21BVCTO1WW dmi.product.sku: LENOVO_MT_21BV_BU_Think_FM_ThinkPad T16 Gen 1 dmi.product.version: ThinkPad T16 Gen 1 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.5-0ubuntu0.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1983815 Title: no detection of the hdmi display moinitor Status in xorg package in Ubuntu: New Bug description: In the windows, hdmi display monitor work. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-43.46-generic 5.15.39 Uname: Linux 5.15.0-43-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.capabilities.gpu0: Error: path was not a regular file. .proc.driver.nvidia.capabilities.mig: Error: path was not a regular file. .proc.driver.nvidia.gpus..03.00.0: Error: path was not a regular file. .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 515.65.01 Wed Jul 20 14:00:58 UTC 2022 GCC version: ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 8 16:27:14 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation Alder Lake-P Integrated Graphics Controller [8086:46a6] (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Lenovo D
