[Touch-packages] [Bug 1970069] Re: Annoying boot messages interfering with splash screen
> You could detect both parameters to avoid that corner case. Sure one can check for "splash nomodeset" to avoid the confusion in most cases, but that wouldn't fix it for "splash $DRIVER.modeset=0" or less common architectures which might have no primary framebuffer. I guess we can tell people who are debugging to remove "splash", and if such a less common architecture did exist then report a new kernel bug that it has no primary framebuffer. Still, I'll keep searching for solutions that don't rely on the primary framebuffer trick. P.S. The patch in comment #55, and anything that follows it, has an unexpected benefit that there is never an onscreen console created if you never VT switched. And so bug 1870041 is also solved (well enough). -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970069/+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 2051540] Re: ufw ftbfs with Python 3.12 as default
** Changed in: ufw (Ubuntu)
Status: In Progress => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/2051540
Title:
ufw ftbfs with Python 3.12 as default
Status in ufw:
Fix Committed
Status in ufw package in Ubuntu:
Confirmed
Status in ufw package in Debian:
Fix Released
Bug description:
==
ERROR: test_ufwcommand_parse
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse)
Test UFWCommand.parse()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 88, in
test_ufwcommand_parse
self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action))
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
==
ERROR: test_ufwcommand_rule_get_command
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command)
Test UFWCommand(Route)Rule.get_command()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 375, in
test_ufwcommand_rule_get_command
self.assertEquals(len(errors), 0,
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
--
Ran 24 tests in 7.584s
FAILED (errors=9)
test_skeleton
test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example)
Test example dummy test ... ok
--
Ran 1 test in 0.000s
OK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2051540/+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 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile
sponsor team, this is the debdiff for mantic thx. ** Patch added: "pulseaudio_16.1+dfsg1-2ubuntu5.debdiff" https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/2051895/+attachment/5744049/+files/pulseaudio_16.1+dfsg1-2ubuntu5.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: In Progress Status in pulseaudio source package in Jammy: In Progress Status in pulseaudio source package in Mantic: In Progress Status in pulseaudio source package in Noble: In Progress Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% [Impact] With the current Ubuntu 22.04 oem image, we try to connect the LENOVO XT99 bt headset and let it work in HFP mode, we select HFP profile from gnome sound-setting, but the microphone will not auto change to bt microphone and the bt output could not work too. So this BT headset could only work in A2DP mode with the current 22.04 OEM image. And we tried ubuntu 22.04 generic image, mantic image and noble image, none of them could make the headset work in HFP mode. [Fix] Cherry-pick a pulseaudio commit from upstream. [Test] Install the patched pulseaudio and reboot, connect to the LENOVO XT99 bt headset, select it to work in HFP mode, tested playback and capture, all worked well. [Where problems could occur] This change will impact bt headset negotiation process in the pulseaudio, so the possiblity of regression is limited to bt headset, it could make the bt headset fail to connect, but this possibility is very low, we tested the patch with different bt headset and bt speaker, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile
sponsor team, this is the debdiff for noble thx. ** Patch added: "pulseaudio_16.1+dfsg1-2ubuntu7.debdiff" https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/2051895/+attachment/5744050/+files/pulseaudio_16.1+dfsg1-2ubuntu7.debdiff ** Changed in: pulseaudio (Ubuntu Jammy) Status: New => In Progress ** Changed in: pulseaudio (Ubuntu Mantic) Status: New => In Progress ** Changed in: pulseaudio (Ubuntu Noble) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: In Progress Status in pulseaudio source package in Jammy: In Progress Status in pulseaudio source package in Mantic: In Progress Status in pulseaudio source package in Noble: In Progress Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% [Impact] With the current Ubuntu 22.04 oem image, we try to connect the LENOVO XT99 bt headset and let it work in HFP mode, we select HFP profile from gnome sound-setting, but the microphone will not auto change to bt microphone and the bt output could not work too. So this BT headset could only work in A2DP mode with the current 22.04 OEM image. And we tried ubuntu 22.04 generic image, mantic image and noble image, none of them could make the headset work in HFP mode. [Fix] Cherry-pick a pulseaudio commit from upstream. [Test] Install the patched pulseaudio and reboot, connect to the LENOVO XT99 bt headset, select it to work in HFP mode, tested playback and capture, all worked well. [Where problems could occur] This change will impact bt headset negotiation process in the pulseaudio, so the possiblity of regression is limited to bt headset, it could make the bt headset fail to connect, but this possibility is very low, we tested the patch with different bt headset and bt speaker, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile
sponsor team, this is the debdiff for jammy thx. ** Description changed: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. - It seems this device cannot switch to Hand free mode in this platform. + It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] - Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. + Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% + + + [Impact] + With the current Ubuntu 22.04 oem image, we try to connect the LENOVO + XT99 bt headset and let it work in HFP mode, we select HFP profile + from gnome sound-setting, but the microphone will not auto change to + bt microphone and the bt output could not work too. So this BT headset + could only work in A2DP mode with the current 22.04 OEM image. + + And we tried ubuntu 22.04 generic image, mantic image and noble image, + none of them could make the headset work in HFP mode. + + [Fix] + Cherry-pick a pulseaudio commit from upstream. + + [Test] + Install the patched pulseaudio and reboot, connect to the LENOVO XT99 + bt headset, select it to work in HFP mode, tested playback and capture, + all worked well. + + [Where problems could occur] + This change will impact bt headset negotiation process in the pulseaudio, + so the possiblity of regression is limited to bt headset, it could make + the bt headset fail to connect, but this possibility is very low, we tested + the patch with different bt headset and bt speaker, all worked well. ** Patch added: "pulseaudio_15.99.1+dfsg1-1ubuntu2.2.debdiff" https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/2051895/+attachment/5744048/+files/pulseaudio_15.99.1+dfsg1-1ubuntu2.2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: In Progress Status in pulseaudio source package in Jammy: In Progress Status in pulseaudio source package in Mantic: In Progress Status in pulseaudio source package in Noble: In Progress Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% [Impact] With the current Ubuntu 22.04 oem image, we try to connect the LENOVO XT99 bt headset and let it work in HFP mode, we select HFP profile from gnome sound-setting, but the microphone will not auto change to bt microphone and the bt output could not work too. So this BT headset could only work in A2DP mode with the current 22.04 OEM image. And we tried ubuntu 22.04 generic image, mantic image and noble image, none of them could make the headset work in HFP mode. [Fix] Cherry-pick a pulseaudio commit from upstream. [Test] Install the patched pulseaudio and reboot, connect to the LENOVO XT99 bt headset, select it to work in HFP mode, tested playback and capture, all worked well. [Where problems could occur] This change will impact bt headset negotiation process in the pulseaudio, so the possiblity of regression is limited to bt headset, it could make the bt headset fail to connect, but this possibility is very low, we tested the patch with different bt headset and bt speaker, all worked well. To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 1958019]
(In reply to Lukas from comment #814) > (In reply to Jacob Garby from comment #813) > > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, > > the speaker started working. I have no idea how -- I did not change > anything > > manually. I suspect it's a new kernel version that did it. > > > > I'm on Arch Linux, and I can't remember which kernel version I have > > installed (but I can update when I get home later today). > > > > Anyway, good news! > > Amazing > > I would like to reproduce this. You can find out your current kernel version > with the command "uname -r". The installed sound packages/libs would also be > interesting. What I know of would be to look at the alsa version. > Someone else surely has more information on what to specificly look for and > how. Yep! I'll post this kind of info before the end of today, check back in a few hours. I can tell you now that the speakers first started working when using pulseaudio as my sound server, but soon after (in order to get bluetooth working nicer) I switched to pipewire. -- 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/1958019 Title: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all Status in sound-2.6 (alsa-kernel): Confirmed Status in alsa-driver package in Ubuntu: Confirmed Bug description: On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux. uname -r 5.11.0-44-generic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22 Uname: Linux 5.11.0-44-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 15 15:10:53 2022 InstallationDate: Installed on 2021-10-11 (96 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2021 dmi.bios.release: 1.49 dmi.bios.vendor: LENOVO dmi.bios.version: GKCN49WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0R32862 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion 7 16ACHg6 dmi.ec.firmware.release: 1.49 dmi.modalias: dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6: dmi.product.family: Legion 7 16ACHg6 dmi.product.name: 82N6 dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 dmi.product.version: Legion 7 16ACHg6 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/sound-2.6/+bug/1958019/+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 1958019]
(In reply to Jacob Garby from comment #813) > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, > the speaker started working. I have no idea how -- I did not change anything > manually. I suspect it's a new kernel version that did it. > > I'm on Arch Linux, and I can't remember which kernel version I have > installed (but I can update when I get home later today). > > Anyway, good news! Amazing I would like to reproduce this. You can find out your current kernel version with the command "uname -r". The installed sound packages/libs would also be interesting. What I know of would be to look at the alsa version. Someone else surely has more information on what to specificly look for and how. -- 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/1958019 Title: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all Status in sound-2.6 (alsa-kernel): Confirmed Status in alsa-driver package in Ubuntu: Confirmed Bug description: On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux. uname -r 5.11.0-44-generic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22 Uname: Linux 5.11.0-44-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 15 15:10:53 2022 InstallationDate: Installed on 2021-10-11 (96 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2021 dmi.bios.release: 1.49 dmi.bios.vendor: LENOVO dmi.bios.version: GKCN49WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0R32862 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion 7 16ACHg6 dmi.ec.firmware.release: 1.49 dmi.modalias: dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6: dmi.product.family: Legion 7 16ACHg6 dmi.product.name: 82N6 dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 dmi.product.version: Legion 7 16ACHg6 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/sound-2.6/+bug/1958019/+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 1958019]
I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, the speaker started working. I have no idea how -- I did not change anything manually. I suspect it's a new kernel version that did it. I'm on Arch Linux, and I can't remember which kernel version I have installed (but I can update when I get home later today). Anyway, good news! -- 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/1958019 Title: [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all Status in sound-2.6 (alsa-kernel): Confirmed Status in alsa-driver package in Ubuntu: Confirmed Bug description: On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux. uname -r 5.11.0-44-generic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22 Uname: Linux 5.11.0-44-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sat Jan 15 15:10:53 2022 InstallationDate: Installed on 2021-10-11 (96 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: i3draven 1266 F pulseaudio /dev/snd/controlC0: i3draven 1266 F pulseaudio /dev/snd/controlC1: i3draven 1266 F pulseaudio /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2021 dmi.bios.release: 1.49 dmi.bios.vendor: LENOVO dmi.bios.version: GKCN49WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0R32862 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Legion 7 16ACHg6 dmi.ec.firmware.release: 1.49 dmi.modalias: dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6: dmi.product.family: Legion 7 16ACHg6 dmi.product.name: 82N6 dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 dmi.product.version: Legion 7 16ACHg6 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/sound-2.6/+bug/1958019/+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 1970069] Re: Annoying boot messages interfering with splash screen
BTW bug 2050743 is making the situation worse on noble. It will be fixed shortly. -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970069/+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 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile
** Also affects: pulseaudio (Ubuntu Noble) Importance: Undecided Status: New ** Also affects: pulseaudio (Ubuntu Mantic) Importance: Undecided Status: New ** Also affects: pulseaudio (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: pulseaudio (Ubuntu Jammy) Importance: Undecided => High ** Changed in: pulseaudio (Ubuntu Mantic) Importance: Undecided => High ** Changed in: pulseaudio (Ubuntu Noble) Importance: Undecided => High ** Changed in: pulseaudio (Ubuntu Jammy) Assignee: (unassigned) => Hui Wang (hui.wang) ** Tags added: oem-priority originate-from-2045342 sutton -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: New Status in pulseaudio source package in Jammy: New Status in pulseaudio source package in Mantic: New Status in pulseaudio source package in Noble: New Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile
** Package changed: linux-oem-6.1 (Ubuntu) => pulseaudio (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/2051895 Title: Lenovo XT99 BT headset can't work in HFP profile Status in HWE Next: New Status in pulseaudio package in Ubuntu: New Status in pulseaudio source package in Jammy: New Status in pulseaudio source package in Mantic: New Status in pulseaudio source package in Noble: New Bug description: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% To manage notifications about this bug go to: https://bugs.launchpad.net/hwe-next/+bug/2051895/+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 2051895] [NEW] Lenovo XT99 BT headset can't work in HFP profile
You have been subscribed to a public bug: [Summary] When use the ThinkPluse xt99 bluetooth head set to run the test com.canonical.certification::bluetooth/audio_record_playback, it cannot record the sound and playback. It seems this device cannot switch to Hand free mode in this platform. [Steps to reproduce] Connect the ThinkPluse xt99, use the Handfree mode, then try to record some voice. [Expected result] The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound. [Actual result] The bluetooth headset xt99 cannot work in the Handfree mode. [Failure rate] 100% ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New -- Lenovo XT99 BT headset can't work in HFP profile https://bugs.launchpad.net/bugs/2051895 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio 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 2051894] [NEW] Cannot activate WWAN connection, repeatedly connects and disconnects very quickly
Public bug reported: I have a SIM installed and activated. If I boot into Windows I can verify connectivity works there. In Ubuntu I can see the connection. When I try to activate it, graphically it toggles on and off very quickly. mccli output is pasted below. I believe all the hardware is fully supported. This laptop can be ordered with Linux (Ubuntu 22.04 LTS) or Windows 10/11. It is a Lenovo ThinkPad z16 gen1 Additionally here's a screen cap of what I'm seeing in the UI https://photos.app.goo.gl/bsoQbF7KPC9zLufr6 # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 06d0e7ce8f0a51e2ae17d0340ef10fe5c0e7794e -- Hardware | manufacturer: Intel | model: MBIM [8086:7560] | firmware revision: 18601.5001.00.01.16.35_TM | h/w revision: V1.3 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 016175005936119 -- System | device: /sys/devices/pci:00/:00:01.3/:05:00.0 |drivers: iosm | plugin: Intel | primary port: wwan0mbim0 | ports: wwan0 (net), wwan0at0 (at), wwan0at1 (at), wwan0mbim0 (mbim) -- Numbers |own: 16318330089ËFsÿ -- Status | unlock retries: sim-pin (3) | state: disabled |power state: low -- Modes| supported: allowed: 3g, 4g; preferred: none |current: allowed: 3g, 4g; preferred: none -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 016175005936119 | enabled locks: fixed-dialing | packet service state: detached -- 3GPP EPS | ue mode of operation: csps-2 | initial bearer ip type: ipv4v6 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: /org/freedesktop/ModemManager1/SIM/1 -- # journalctl -f -u NetworkManager.service Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2611] policy: auto-activating connection 'Google-Fi' (05250c1d-91b1-420c-99ec-f922b318a83d) Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2614] device (wwan0mbim0): Activation: starting connection 'Google-Fi' (05250c1d-91b1-420c-99ec-f922b318a83d) Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2614] device (wwan0mbim0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2781] device (wwan0mbim0): state change: prepare -> disconnected (reason 'user-requested', sys-iface-state: 'managed') Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2787] policy: auto-activating connection 'Google-Fi' (05250c1d-91b1-420c-99ec-f922b318a83d) Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2791] device (wwan0mbim0): Activation: starting connection 'Google-Fi' (05250c1d-91b1-420c-99ec-f922b318a83d) Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2791] device (wwan0mbim0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2795] device (wwan0mbim0): state change: prepare -> deactivating (reason 'user-requested', sys-iface-state: 'managed') Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.2797] audit: op="device-disconnect" interface="wwan0mbim0" pid=3422 uid=1000 result="success" Jan 31 20:32:10 nickh-ThinkPad-Z16 NetworkManager[1115]: [1706754730.3267] device (wwan0mbim0): state change: deactivating -> disconnected (reason 'user-requested', sys-iface-state: 'managed') ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: modemmanager 1.20.6-1ubuntu1 ProcVersionSignature: Ubuntu 6.5.0-15.15-generic 6.5.3 Uname: Linux 6.5.0-15-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Wed Jan 31 20:27:22 2024 InstallationDate: Installed on 2024-01-30 (1 days ago) InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user)
[Touch-packages] [Bug 2051405] Re: ProtectHome setting in debian/rsyslog.service isn't understood by systemd
With the change an autopkgtests succeeded but an upgrade failed. ** Changed in: rsyslog (Ubuntu) Assignee: (unassigned) => Heinrich Schuchardt (xypron) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/2051405 Title: ProtectHome setting in debian/rsyslog.service isn't understood by systemd Status in rsyslog package in Ubuntu: Confirmed Bug description: Small bug introduced in commit e175f5c3668adc1c65f66efb61f70060569c9fe8 https://git.launchpad.net/ubuntu/+source/rsyslog/commit/?id=e175f5c3668adc1c65f66efb61f70060569c9fe8 which changed the rsyslog.service line of ProtectHome=yes to ProtectHome=readonly Systemd doesn't understand "readonly" https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html and will mention in its journal: systemd[1]: /lib/systemd/system/rsyslog.service:24: Failed to parse protect home value, ignoring: readonly Quickfix: just needs a hyphen on line 24 to read 'read-only' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2051405/+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 1782709] Re: Updating systemd kills network on bionic
I have the same problem and every time I upgrade systemd, it kills my network access to the server. I therefore had to disable automatic updates and always run a shutdown -r 10 command before upgrading -- 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/1782709 Title: Updating systemd kills network on bionic Status in linux package in Ubuntu: Expired Status in systemd package in Ubuntu: Invalid Bug description: I do have an ubuntu bionic server installation without a graphical interface. The server has two active network adapters, both connected to the internet. One is used for outgoing internet traffic, the other for incoming. The incoming adapter lives on a public network segment (something like 88.236.133.104/29). I do have multiple servers within this segment. Typically, I update the server regularly, meaning: * ssh to the incoming adapter: ssh 88.236.133.108 * apt-get update * apt-get upgrade * apt-get dist-upgrade * apt-get clean * reboot It used to work ok. BUT: Today, "apt-get upgrade" seem to take really long when updating systemd. After a could of minutes, I realized that the ssh session became inactive. I couldn't type into it, I had to abort it via ~. . * ssh from the internet to the incoming adapter was not working anymore - ssh 88.236.133.108 * ssh via another server within the public network segment worked * ssh 88.236.133.106 -> ssh 88.236.133.108 * After running "netplan apply" everything was fine again Here my netplan configuration (I changed the ip addresses): network: version: 2 renderer: networkd ethernets: eno1: dhcp4: yes eno2: dhcp4: no addresses: [88.236.133.108/29] #gateway4: 88.236.133.105 routes: - to: 0.0.0.0/0 via: 88.236.133.105 table: 120 routing-policy: - from: 88.236.133.108/32 table: 120 - to: 88.236.133.108/32 table: 120 Unfortunately, I don't have the console output avalable anymore. Shall I provide additional info? Best regards, Uli --- ProblemType: Bug AlsaDevices: total 0 crw-rw 1 root audio 116, 1 Jul 20 08:10 seq crw-rw 1 root audio 116, 33 Jul 20 08:10 timer AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay' ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: DistroRelease: Ubuntu 18.04 InstallationDate: Installed on 2018-07-14 (5 days ago) InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig' MachineType: IBM IBM System x -[794582G]- Package: linux (not installed) PciMultimedia: ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=de_DE.UTF-8 SHELL=/bin/bash ProcFB: 0 mgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-23-generic root=UUID=a41b3020-8359-4fe2-8fc3-1c97011f71ec ro ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 RelatedPackageVersions: linux-restricted-modules-4.15.0-23-generic N/A linux-backports-modules-4.15.0-23-generic N/A linux-firmware 1.173.1 RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill' Tags: bionic Uname: Linux 4.15.0-23-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: _MarkForUpload: True dmi.bios.date: 05/07/2014 dmi.bios.vendor: IBM Corp. dmi.bios.version: -[D6E162AUS-1.20]- dmi.board.asset.tag: (none) dmi.board.name: 00D4062 dmi.board.vendor: IBM dmi.board.version: (none) dmi.chassis.asset.tag: none dmi.chassis.type: 23 dmi.chassis.vendor: IBM dmi.chassis.version: none dmi.modalias: dmi:bvnIBMCorp.:bvr-[D6E162AUS-1.20]-:bd05/07/2014:svnIBM:pnIBMSystemx-[794582G]-:pvr00:rvnIBM:rn00D4062:rvr(none):cvnIBM:ct23:cvrnone: dmi.product.family: System x dmi.product.name: IBM System x -[794582G]- dmi.product.version: 00 dmi.sys.vendor: IBM To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1782709/+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 2051540] Re: ufw ftbfs with Python 3.12 as default
I'll upload a fix for that tomorrow.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/2051540
Title:
ufw ftbfs with Python 3.12 as default
Status in ufw:
Fix Committed
Status in ufw package in Ubuntu:
In Progress
Status in ufw package in Debian:
Fix Released
Bug description:
==
ERROR: test_ufwcommand_parse
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse)
Test UFWCommand.parse()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 88, in
test_ufwcommand_parse
self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action))
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
==
ERROR: test_ufwcommand_rule_get_command
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command)
Test UFWCommand(Route)Rule.get_command()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 375, in
test_ufwcommand_rule_get_command
self.assertEquals(len(errors), 0,
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
--
Ran 24 tests in 7.584s
FAILED (errors=9)
test_skeleton
test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example)
Test example dummy test ... ok
--
Ran 1 test in 0.000s
OK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2051540/+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 2051540] Re: ufw ftbfs with Python 3.12 as default
Another fix is needed for python 3.12:
Performing tests 'good/reports'
- installing
- result:
FAIL:
4a5,8
> /<>/tests/testarea/lib/python/ufw/util.py:483: SyntaxWarning:
> invalid escape sequence '\.'
> quads = re.split('\.', nm)
> /<>/tests/testarea/lib/python/ufw/util.py:745: SyntaxWarning:
> invalid escape sequence '\s'
> tmp = re.split('\s', out)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/2051540
Title:
ufw ftbfs with Python 3.12 as default
Status in ufw:
Fix Committed
Status in ufw package in Ubuntu:
In Progress
Status in ufw package in Debian:
Fix Released
Bug description:
==
ERROR: test_ufwcommand_parse
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse)
Test UFWCommand.parse()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 88, in
test_ufwcommand_parse
self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action))
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
==
ERROR: test_ufwcommand_rule_get_command
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command)
Test UFWCommand(Route)Rule.get_command()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 375, in
test_ufwcommand_rule_get_command
self.assertEquals(len(errors), 0,
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
--
Ran 24 tests in 7.584s
FAILED (errors=9)
test_skeleton
test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example)
Test example dummy test ... ok
--
Ran 1 test in 0.000s
OK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2051540/+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 2051405] Re: ProtectHome setting in debian/rsyslog.service isn't understood by systemd
rsyslog - 8.2312.0-3ubuntu3 is available in ppa:xypron/rsyslog2312. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/2051405 Title: ProtectHome setting in debian/rsyslog.service isn't understood by systemd Status in rsyslog package in Ubuntu: Confirmed Bug description: Small bug introduced in commit e175f5c3668adc1c65f66efb61f70060569c9fe8 https://git.launchpad.net/ubuntu/+source/rsyslog/commit/?id=e175f5c3668adc1c65f66efb61f70060569c9fe8 which changed the rsyslog.service line of ProtectHome=yes to ProtectHome=readonly Systemd doesn't understand "readonly" https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html and will mention in its journal: systemd[1]: /lib/systemd/system/rsyslog.service:24: Failed to parse protect home value, ignoring: readonly Quickfix: just needs a hyphen on line 24 to read 'read-only' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2051405/+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 1790418] Re: ditch ipconfig entirely in 19.04
There is just one call to ipconfig remaining (and some comments that mention it, which should be reworded too): https://git.launchpad.net/ubuntu/+source/initramfs- tools/tree/scripts/functions?id=ac80d4f629320182473195adcb715f6a691c5123#n442 -- 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/1790418 Title: ditch ipconfig entirely in 19.04 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: Bug 1782802 used to be about ripping ipconfig entirely out of the initramfs. But that was too hard to do for cosmic, hence this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1790418/+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 1782802] Re: use dhclient -4 instead of ipconfig in easy cases in 18.10
This can be closed since bug 2024164 replaced dhclient with dhcpcd. -- 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/1782802 Title: use dhclient -4 instead of ipconfig in easy cases in 18.10 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: When adding ipv6 netboot support to initramfs-tools in yakkety/zesty, this was initially attempted with replacing ipconfig with dhclient. As described in LP: #1621507, the use of dhclient for ipv4 dhcp was backed out in favor of ipconfig. So at the moment, we are using both ipconfig from klibc-utils and dhclient from isc-dhcp-client in the initramfs. We want to switch off of klibc-utils completely and use isc-dhcp- client for both ipv4 and ipv6 in initramfs-tools. But for cosmic, we'll only do the easy bits. Bug 1790418 is about finishing the job. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1782802/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
The test passed w/ flock as well: https://autopkgtest.ubuntu.com/results/autopkgtest-noble-dannf-loop/noble/amd64/l/livecd-rootfs/20240131_104633_df869@/log.gz 274 successful iterations before the timeout killed it. I've updated the MP: https://code.launchpad.net/~dannf/livecd-rootfs/+git/livecd-rootfs/+merge/459549 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable
** Merge proposal linked: https://code.launchpad.net/~dannf/livecd-rootfs/+git/livecd-rootfs/+merge/459549 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/2045586 Title: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable Status in linux package in Ubuntu: New Status in livecd-rootfs package in Ubuntu: Fix Released Status in util-linux package in Ubuntu: New Bug description: In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, with the expectation that this would give us a reliable, race- free way of loop-mounting partitions from a disk image during image build. In noble, we are finding that it is no longer reliable, and in fact fails rather often. It is most noticeable with riscv64 builds, which is the architecture where we most frequently ran into problems before with kpartx. The first riscv64+generic build in noble where the expected loop partition device is not available is https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/531790 The failure is however not unique to riscv64, and the autopkgtest for the latest version of livecd-rootfs (24.04.7) - an update that specifically tries to add more debugging code for this scenario - has also failed on ppc64el. https://autopkgtest.ubuntu.com/packages/l/livecd- rootfs/noble/ppc64el The first failure happened on November 16. While there has been an update to the util-linux package in noble, this did not land until November 23. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+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 2002043] Re: Python extension modules get built using wrong compiler flags with python2
** Description changed: [ Impact ] When compiling Python extensions using Python2, CFLAGS optimization flags are dropped. This behavior has been caused by our update in this patch http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz which differs from upstream. The fix modifies the portion of code in Lib/distutils/sysconfig.py which gets the cflags from the environments, and includes the dropped OPT flag from get_config_vars(). [ Test Plan ] There will be 2 separate tests for this bug: * Ensuring no-change rebuilds are not changed * Ensuring local builds are not changed unless environment variable is set Test 1) No-change rebuilds To test that no-change rebuilds are not changed, the package python- stdlib-extensions will be built against the new python2.7, and confirm the compiler flags are not altered. This will be a manual test and visual inspection of the build logs. Test 2) Functional test 1. Create test container - $ lxc launch ubuntu:jammy jammy-2002043 + $ lxc launch ubuntu:jammy jammy-2002043 $ lxc shell ubuntu:jammy jammy-2002043 2. Install required packages + For Jammy # apt update -y && apt install -y python2 python-pip + For Focal + # apt update -y && apt install -y python2 python-setuptools 3. Create test files # mkdir testprog # cd testprog # cat >setup.py
[Touch-packages] [Bug 1782802] Re: use dhclient -4 instead of ipconfig in easy cases in 18.10
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: initramfs-tools (Ubuntu) Status: New => Confirmed -- 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/1782802 Title: use dhclient -4 instead of ipconfig in easy cases in 18.10 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: When adding ipv6 netboot support to initramfs-tools in yakkety/zesty, this was initially attempted with replacing ipconfig with dhclient. As described in LP: #1621507, the use of dhclient for ipv4 dhcp was backed out in favor of ipconfig. So at the moment, we are using both ipconfig from klibc-utils and dhclient from isc-dhcp-client in the initramfs. We want to switch off of klibc-utils completely and use isc-dhcp- client for both ipv4 and ipv6 in initramfs-tools. But for cosmic, we'll only do the easy bits. Bug 1790418 is about finishing the job. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1782802/+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 1790418] Re: ditch ipconfig entirely in 19.04
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: initramfs-tools (Ubuntu) Status: New => Confirmed -- 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/1790418 Title: ditch ipconfig entirely in 19.04 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: Bug 1782802 used to be about ripping ipconfig entirely out of the initramfs. But that was too hard to do for cosmic, hence this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1790418/+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 2042587] Update Released
The verification of the Stable Release Update for dnsmasq has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2042587 Title: jammy's version breaks existing dhcp scripts with relay Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: Fix Released Bug description: [ Impact ] When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. This was fixed in 2.87, therefore making only jammy carry an affected package. [ Test Plan ] To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration. # Launch a jammy VM lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm # open a root shell in that VM. All subsequent commands must be executed as root in that VM lxc shell j-dnsmasq-2042587 # download test script wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup- and-server.sh # make it executable chmod +x setup-and-server.sh # install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict) apt update && apt install dnsmasq -y # run the setup script. It will configure things and start dnsmasq ready to be tested ./setup-and-server.sh # in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown): No DHCP relay: ip netns exec client dhclient -d -v p2 The setup script should log an IP that is not a relay. For example: dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587 ### IP = 192.168.47.150 ### With DHCP relay set to 192.168.47.9, IP should NOT be that address: ip netns exec client dhclient -d -v p2 -g 192.168.47.9 With the affected dnsmasq package, we will see an error: dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587 ### IP = 192.168.47.9 TEST FAILED ### The error is that the obtained IP is that of the dhcp relay (provided via the -g option). With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay. [ Where problems could occur ] If the fix is incorrect, it would mean the dhcp-script would get an incorrect IP again, or perhaps we could have crashes in dnsmasq when dealing with buffers and pointers if the dhcp-script option is in use. This fix was committed upstream a few months after the bug was introduced, so it took a while to be noticed. [ Other Info ] Not at this time. [ Original description ] When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp- script: > The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known. I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address). dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+subscriptions
[Touch-packages] [Bug 2042587] Re: jammy's version breaks existing dhcp scripts with relay
This bug was fixed in the package dnsmasq - 2.86-1.1ubuntu0.5 --- dnsmasq (2.86-1.1ubuntu0.5) jammy; urgency=medium * src/dnsmasq.c: Fix a crash that can happen when an empty resolv.conf is reloaded (LP: #2045570) * src/helper.c: Fix wrong client address for dhcp-script when DHCPv4 relay in use (LP: #2042587) -- Andreas Hasenack Thu, 11 Jan 2024 09:21:27 -0300 ** Changed in: dnsmasq (Ubuntu Jammy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2042587 Title: jammy's version breaks existing dhcp scripts with relay Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: Fix Released Bug description: [ Impact ] When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. This was fixed in 2.87, therefore making only jammy carry an affected package. [ Test Plan ] To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration. # Launch a jammy VM lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm # open a root shell in that VM. All subsequent commands must be executed as root in that VM lxc shell j-dnsmasq-2042587 # download test script wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup- and-server.sh # make it executable chmod +x setup-and-server.sh # install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict) apt update && apt install dnsmasq -y # run the setup script. It will configure things and start dnsmasq ready to be tested ./setup-and-server.sh # in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown): No DHCP relay: ip netns exec client dhclient -d -v p2 The setup script should log an IP that is not a relay. For example: dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587 ### IP = 192.168.47.150 ### With DHCP relay set to 192.168.47.9, IP should NOT be that address: ip netns exec client dhclient -d -v p2 -g 192.168.47.9 With the affected dnsmasq package, we will see an error: dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587 ### IP = 192.168.47.9 TEST FAILED ### The error is that the obtained IP is that of the dhcp relay (provided via the -g option). With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay. [ Where problems could occur ] If the fix is incorrect, it would mean the dhcp-script would get an incorrect IP again, or perhaps we could have crashes in dnsmasq when dealing with buffers and pointers if the dhcp-script option is in use. This fix was committed upstream a few months after the bug was introduced, so it took a while to be noticed. [ Other Info ] Not at this time. [ Original description ] When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp- script: > The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known. I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address). dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 To manage notifications about this bug go to:
[Touch-packages] [Bug 2045570] Update Released
The verification of the Stable Release Update for dnsmasq has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2045570 Title: dnsmasq crash when no servers in resolv.conf Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: Fix Released Bug description: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected. 1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803 The commit message says: """ This problem was introduced in 2.86. """ And indeed, I wasn't able to crash 2.80 shipped in focal. [ Test Plan ] It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. # Create a jammy lxd container lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 # Enter the container lxc shell j-dnsmasq-2045570 # From now on, all commands should be executed in the container. # Install dnsmasq, and disable systemd-resolved apt update && apt install -y dnsmasq # Disable systemd-resolved, and start dnsmasq systemctl disable --now systemd-resolved systemctl enable --now dnsmasq # In one terminal inside the container, watch the dnsmasq logs: journalctl -u dnsmasq.service -f # In another terminal, remove /etc/resolv.conf and create a new one, empty rm /etc/resolv.conf echo "nameserver 1.1.1.1" > /etc/resolv.conf # restart dnsmasq systemctl restart dnsmasq.service # Perform a dns query dig @127.0.0.1 +short linux.com # Comment the namserver directive in resolv.conf echo "#nameserver 1.1.1.1" > /etc/resolv.conf # Observe in the dnsmasq logs that it notices the change with a message like: Jan 03 14:14:51 j-dnsmasq-2045570 dnsmasq[2274]: no servers found in /etc/resolv.conf, will retry # Perform a *different* DNS query dig @127.0.0.1 +short ubuntu.com # Observe in the dnsmasq logs that it crashes. Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: - add "nameserver 127.0.0.1" to /etc/resolv.conf - observe that dnsmasq notices the change to the file - perform a query for some random domain using "dig @127.0.0.1 +short " - remove "nameserver" from
[Touch-packages] [Bug 2045570] Re: dnsmasq crash when no servers in resolv.conf
This bug was fixed in the package dnsmasq - 2.86-1.1ubuntu0.5 --- dnsmasq (2.86-1.1ubuntu0.5) jammy; urgency=medium * src/dnsmasq.c: Fix a crash that can happen when an empty resolv.conf is reloaded (LP: #2045570) * src/helper.c: Fix wrong client address for dhcp-script when DHCPv4 relay in use (LP: #2042587) -- Andreas Hasenack Thu, 11 Jan 2024 09:21:27 -0300 ** Changed in: dnsmasq (Ubuntu Jammy) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2045570 Title: dnsmasq crash when no servers in resolv.conf Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: Fix Released Bug description: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected. 1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803 The commit message says: """ This problem was introduced in 2.86. """ And indeed, I wasn't able to crash 2.80 shipped in focal. [ Test Plan ] It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. # Create a jammy lxd container lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 # Enter the container lxc shell j-dnsmasq-2045570 # From now on, all commands should be executed in the container. # Install dnsmasq, and disable systemd-resolved apt update && apt install -y dnsmasq # Disable systemd-resolved, and start dnsmasq systemctl disable --now systemd-resolved systemctl enable --now dnsmasq # In one terminal inside the container, watch the dnsmasq logs: journalctl -u dnsmasq.service -f # In another terminal, remove /etc/resolv.conf and create a new one, empty rm /etc/resolv.conf echo "nameserver 1.1.1.1" > /etc/resolv.conf # restart dnsmasq systemctl restart dnsmasq.service # Perform a dns query dig @127.0.0.1 +short linux.com # Comment the namserver directive in resolv.conf echo "#nameserver 1.1.1.1" > /etc/resolv.conf # Observe in the dnsmasq logs that it notices the change with a message like: Jan 03 14:14:51 j-dnsmasq-2045570 dnsmasq[2274]: no servers found in /etc/resolv.conf, will retry # Perform a *different* DNS query dig @127.0.0.1 +short ubuntu.com # Observe in the dnsmasq logs that it crashes. Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: - add "nameserver 127.0.0.1" to /etc/resolv.conf - observe that dnsmasq notices the change to the file - perform a query for some random domain using "dig @127.0.0.1 +short " - remove "nameserver" from
[Touch-packages] [Bug 2040389] Re: Sync libmnl from Debian unstable for noble
** Changed in: libmnl (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libmnl in Ubuntu. https://bugs.launchpad.net/bugs/2040389 Title: Sync libmnl from Debian unstable for noble Status in libmnl package in Ubuntu: Fix Released Bug description: Scheduled-For: Backlog Upstream: tbd Debian: 1.0.5.2 Ubuntu: 1.0.4-3ubuntu1 There is nothing yet to merge for libmnl currently, but this ticket is filed prospectfully for tracking purposes in case a merge does become available later this cycle. If it turns out this needs a sync rather than a merge, please change the tag 'needs-merge' to 'needs-sync', and (optionally) update the title as desired. ### Old Ubuntu Delta ### libmnl (1.0.4-3ubuntu1) kinetic; urgency=medium * Static build does not work for libmnl (-lmnl) (LP: #1971523) -- Michal Maloszewski Thu, 21 Jul 2022 14:02:16 +0200 libmnl (1.0.4-3build2) jammy; urgency=high * No change rebuild for ppc64el baseline bump. -- Julian Andres Klode Thu, 24 Mar 2022 13:13:28 +0100 libmnl (1.0.4-3build1) impish; urgency=medium * No-change rebuild to build packages with zstd compression. -- Matthias Klose Thu, 07 Oct 2021 12:16:42 +0200 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libmnl/+bug/2040389/+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 2051540] Re: ufw ftbfs with Python 3.12 as default
** Changed in: ufw (Debian)
Status: Unknown => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/2051540
Title:
ufw ftbfs with Python 3.12 as default
Status in ufw:
Fix Committed
Status in ufw package in Ubuntu:
In Progress
Status in ufw package in Debian:
Fix Released
Bug description:
==
ERROR: test_ufwcommand_parse
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse)
Test UFWCommand.parse()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 88, in
test_ufwcommand_parse
self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action))
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
==
ERROR: test_ufwcommand_rule_get_command
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command)
Test UFWCommand(Route)Rule.get_command()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 375, in
test_ufwcommand_rule_get_command
self.assertEquals(len(errors), 0,
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
--
Ran 24 tests in 7.584s
FAILED (errors=9)
test_skeleton
test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example)
Test example dummy test ... ok
--
Ran 1 test in 0.000s
OK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2051540/+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 2049318] Re: [SRU] free(): double free detected in tcache 2
Thank you for preparing the SRU and for testing! The Test Plan agreed in the bug description included two cases but it looks like you only did the first one? Given that a different SRU team member did the review and agreed the fully stated plan, I don't feel that I'm in a position to then release based on only half of it. Please could you complete the other part? ** Tags removed: verification-done verification-done-jammy ** Tags added: verification-needed verification-needed-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/2049318 Title: [SRU] free(): double free detected in tcache 2 Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Jammy: Fix Committed Bug description: [ Impact ] iptables is unable to list the iptables rules or save the iptables rules if a nftables ruleset is defined which iptables does not recognize. [ Test Plan ] 1. Simple test plan based on upstream test case: sudo nft -f - < rules.txt * Convert the rule to nftables ruleset - sudo iptables-nft-restore < rules.txt * List the nftables ruleset - sudo nft list ruleset * Also confirm that iptables can list the old rule - sudo iptables -L * Now add another nftables rule (this rule is taken from upstream test case) sudo nft -f -
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
** Changed in: ufw
Status: New => Fix Committed
** Changed in: ufw
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
** Changed in: ufw (Ubuntu)
Status: Confirmed => In Progress
** Changed in: ufw (Ubuntu)
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
** Bug watch added: Debian Bug tracker #1061763
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061763
** Also affects: ufw (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061763
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/2051540
Title:
ufw ftbfs with Python 3.12 as default
Status in ufw:
Fix Committed
Status in ufw package in Ubuntu:
In Progress
Status in ufw package in Debian:
Unknown
Bug description:
==
ERROR: test_ufwcommand_parse
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_parse)
Test UFWCommand.parse()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 88, in
test_ufwcommand_parse
self.assertEquals('status', pr.action, "%s != 'status'" % (pr.action))
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
==
ERROR: test_ufwcommand_rule_get_command
(tests.unit.test_parser.ParserTestCase.test_ufwcommand_rule_get_command)
Test UFWCommand(Route)Rule.get_command()
--
Traceback (most recent call last):
File "/<>/tests/unit/test_parser.py", line 375, in
test_ufwcommand_rule_get_command
self.assertEquals(len(errors), 0,
^
AttributeError: 'ParserTestCase' object has no attribute 'assertEquals'. Did
you mean: 'assertEqual'?
--
Ran 24 tests in 7.584s
FAILED (errors=9)
test_skeleton
test_example (tests.unit.test_skeleton.SkeletonTestCase.test_example)
Test example dummy test ... ok
--
Ran 1 test in 0.000s
OK
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2051540/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems
PS: the Jammy verification done in comment 31 used version 2.37.2-4ubuntu3.1 (staged in this bug), and that in comment 39 used (newer) version 2.37.2-4ubuntu3.2 (also staged, in bug 2048092) -- both have positive results. BTW, since the newer upload is still planned for staging, not removing the block-proposed-jammy tag, IIUIC. """ In principle the block-proposed- tag should be removed by an SRU team member when accepting a newer upload not planned for further staging. But if they overlook this, it's appropriate for whoever notices it (SRU team, or uploader) to remove the block-proposed- tag with a suitable comment when it no longer applies. """ @ https://wiki.ubuntu.com/StableReleaseUpdates#Staging_an_upload -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/2019856 Title: Add missing ARM-cores to support Grace-based systems Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Jammy: Fix Committed Status in util-linux source package in Kinetic: Won't Fix Status in util-linux source package in Lunar: Won't Fix Status in util-linux source package in Mantic: Fix Released Bug description: [Impact] When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't report a model name: Vendor ID: ARM Model: 0 [Fix] Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. The commit below adds the specific codes missing from Jammy's version. https://github.com/util-linux/util- linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740 [Test Steps] * Verify whether output of lscpu is correct on new CPUs; eg: Vendor ID: ARM Model name: Neoverse-V2 * Verify whether output of lscpu doesn't change on old CPUs; eg: Vendor ID: ARM Model name: Neoverse-N1 [What Could Go Wrong] The fix only introduces additional model identifiers to match against and print a model name string, thus regression impact should be contained within lscpu and printing cpus model name on ARM systems. Output doesn't change on systems with non-affected CPU models. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 1970069] Re: Annoying boot messages interfering with splash screen
You could detect both parameters to avoid that corner case. Alternatively this is something I feel simpledrm will help you avoid hitting too. Otherwise it sounds good to me. -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970069/+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 2019856] Re: Add missing ARM-cores to support Grace-based systems
Jammy verification done in comments 31 (with tag flip) and 39. Lunar is now Won't Fix (2024-01-17), thus removing lunar tags. ** Tags removed: block-proposed-lunar verification-done-lunar -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/2019856 Title: Add missing ARM-cores to support Grace-based systems Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Jammy: Fix Committed Status in util-linux source package in Kinetic: Won't Fix Status in util-linux source package in Lunar: Won't Fix Status in util-linux source package in Mantic: Fix Released Bug description: [Impact] When running "lscpu" on a Grace-based system + Ubuntu 22.04, it doesn't report a model name: Vendor ID: ARM Model: 0 [Fix] Adding the additional arm_part to sys-utils/lscpu-arm.c solves the problem. The commit below adds the specific codes missing from Jammy's version. https://github.com/util-linux/util- linux/commit/6857cccbb4157d5da34ca98f77a0ac9d68e1e740 [Test Steps] * Verify whether output of lscpu is correct on new CPUs; eg: Vendor ID: ARM Model name: Neoverse-V2 * Verify whether output of lscpu doesn't change on old CPUs; eg: Vendor ID: ARM Model name: Neoverse-N1 [What Could Go Wrong] The fix only introduces additional model identifiers to match against and print a model name string, thus regression impact should be contained within lscpu and printing cpus model name on ARM systems. Output doesn't change on systems with non-affected CPU models. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/2019856/+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 1970069] Re: Annoying boot messages interfering with splash screen
A new attempt at a kernel patch. While this is pleasingly simple and reliable in my own testing, it has a bug when "splash" is used at the same time as there being no primary framebuffer (like with "nomodeset"). I'm not sure if that's a realistic concern and am reluctant to go back to delays to paper over it. What do others think? ** Patch added: "fbcon-Optionally-defer-takeover-further-for-the-prim-v1.patch" https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1970069/+attachment/5743890/+files/fbcon-Optionally-defer-takeover-further-for-the-prim-v1.patch -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970069/+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 539814] Re: tar: futimens() with a bad file descriptor (AT_FDCWD) causes bootstrapping failure with kernels < 2.6.22
Can the whole task for Ubuntu be marked wontfix? (I can't do it) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tar in Ubuntu. https://bugs.launchpad.net/bugs/539814 Title: tar: futimens() with a bad file descriptor (AT_FDCWD) causes bootstrapping failure with kernels < 2.6.22 Status in Release Notes for Ubuntu: Fix Released Status in debootstrap package in Ubuntu: Triaged Status in tar package in Ubuntu: Fix Released Status in debootstrap source package in Lucid: Won't Fix Status in tar source package in Lucid: Fix Released Status in tar package in Debian: Fix Released Status in tar package in Fedora: Fix Released Bug description: Binary package hint: tar Bootstrapping Ubuntu Lucid with debootstrap is currently impossible with any kernel < 2.6.22, due to a bug in tar - specifically it fails because of a change to eglibc. According to the debian bug report It seems that before eglibc 2.10.2-3, calls to futimens failed silently, however due to a patch made to eglibc 2.10.2-3, if futimens is called without a valid file descriptor, it now fails with an "Bad File Descriptor" error, because the corresponding utimensat() syscall was not added until kernel 2.6.22 Test Case: 1) Boot a kernel older than 2.6.22 2) Attempt to Bootstrap Ubuntu Lucid to any target. The bootstrap will fail once it attempts to unpack packages with: tar: ./postinst: Cannot utime: Bad file descriptor A patch is available (attached in launchpad) originating from the associated debian bug, that ensures that futimens is only called with a valid file descriptor. A debdiff for 1.22-2 ( changing to 1.22-2ubuntu1 ) will be attached shortly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/539814/+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 1950906] Re: etc/rc.local should Want or Require network-online.target
I must agree with Michael Tokarev. I too decideed to do some local stuff using rc-local and now my bootup hangs unneccessarily for a few seconds each time waiting for NetworkManager to establish a connection. Here's a crazy idea: why not have an rc-local-with-network in which one can dump all the local stuff that needs networking and everything else can go into the normal rc-local? I'll go configure this right now on my system :) -- 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/1950906 Title: etc/rc.local should Want or Require network-online.target Status in systemd package in Ubuntu: New Bug description: The fix for bug #1451797 introduced /lib/systemd/system/rc- local.service.d/debian.conf with the intent that rc.local would always run after the network was fully online. However, it only has an After= line, without actually pulling in network-online.target. Systemd docs say: "Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. ... Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) ... Usually, network.target is part of the boot of most systems, while network-online.target is not ..." TL;DR - need to add "Wants=network-online.target" to /lib/systemd/system/rc-local.service.d/debian.conf :) ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.13 ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148 Uname: Linux 5.4.0-90-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: Xpra CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Sun Nov 14 17:22:54 2021 InstallationDate: Installed on 2017-01-08 (1771 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M MachineType: Dell Inc. OptiPlex 3040 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-90-generic root=/dev/mapper/lvg2-host ro rootflags=subvol=rootfs rw drm.edid_firmware=edid/toguard2.bin video=HDMI-A-1:1024x768@60D SourcePackage: systemd UpgradeStatus: Upgraded to focal on 2021-09-02 (73 days ago) acpidump: dmi.bios.date: 06/30/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.4.6 dmi.board.name: 0TTDMJ dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 3 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.4.6:bd06/30/2016:svnDellInc.:pnOptiPlex3040:pvr:rvnDellInc.:rn0TTDMJ:rvrA00:cvnDellInc.:ct3:cvr: dmi.product.name: OptiPlex 3040 dmi.product.sku: 06BB dmi.sys.vendor: Dell Inc. mtime.conffile..etc.systemd.logind.conf: 2019-03-03T09:57:30.814201 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950906/+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 1938058] Re: systemd-time-wait-sync.service should be part of systemd-timesyncd package
** Also affects: systemd (Ubuntu Noble) Importance: Low Status: Triaged ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New -- 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/1938058 Title: systemd-time-wait-sync.service should be part of systemd-timesyncd package Status in systemd package in Ubuntu: Triaged Status in systemd source package in Focal: Triaged Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Won't Fix Status in systemd source package in Jammy: New Status in systemd source package in Noble: Triaged Bug description: [impact] systemd-time-wait-sync service never completes when systemd-timesyncd package is not installed [test case] remove the systemd-timesyncd package and enable the systemd-time-wait- sync service, and reboot. Check status of the service to see it's stuck in 'activating' state, e.g.: ubuntu@lp1937238-f:~$ sudo systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Fri 2021-07-23 15:32:12 UTC; 19s ago [regression potential] TBD [scope] this is needed in f and later the systemd-timesyncd package was split out from the main systemd package starting in focal, so this problem exists in f and later the service doesn't exist in b, so this is not needed there [other info] originally noticed in bug 1937238, but create this new bug in case that bug was actually a separate problem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1938058/+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 2044104] Comment bridged from LTC Bugzilla
--- Comment From peter.oberparlei...@de.ibm.com 2024-01-31 04:28 EDT--- (In reply to comment #22) > Then `/sbin/chzdev --is-author-of-udev-rule "$rules"` should produce the > correct exit code. The tool that generates the udev rules should be queried > (is that chzdev or something else?) or a separate helper should be used. > > Re-assinging from initramfs-tools to systemd, because > /usr/share/initramfs-tools/hooks/udev is shipped by udev. I agree with this approach. Yes, the udev rules are generated by chzdev, so we'll work on adding a chzdev command line option that can be used to query ownership of a udev rule/configuration file similar to what is as outlined above. I'll update this bug report once the option as available in upstream s390-tools. -- 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/2044104 Title: [UBUNTU 20.04] chzdev -e is rebuilding initramfs even with zdev:early=0 set Status in Ubuntu on IBM z Systems: New Status in s390-tools package in Ubuntu: New Status in systemd package in Ubuntu: New Status in s390-tools source package in Noble: New Status in systemd source package in Noble: New Bug description: Versions: Ubuntu 20.04.5 s390-tools version 2.12.0-0ubuntu3.7.s390x Ubuntu 22.04.2 s390-tools version 2.20.0-0ubuntu3.2.s390x When I configure a zfcp LUN persistently via chzdev, the initrd is being rebuilt even with parameter zdev:early=0 root@a8315003:~# chzdev -e zfcp-lun 0.0.1803:0x500507630910d430:0x40194092 zdev:early=0 zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 configured Note: The initial RAM-disk must be updated for these changes to take effect: - zFCP LUN 0.0.1803:0x500507630910d430:0x40194092 update-initramfs: Generating /boot/initrd.img-5.15.0-60-generic I: The initramfs will attempt to resume from /dev/dasdb1 I: (UUID=e70ecb80-4d1e-4074-9cda-ce231ad6e698) I: Set the RESUME variable to override this. Using config file '/etc/zipl.conf' Building bootmap in '/boot' Adding IPL section 'ubuntu' (default) Preparing boot device: dasda (c00a). Done. root@a8315003:~# == Comment: - Thorsten Diehl - 2023-03-01 06:55:47 == @BOE-dev This behaviour is unexpected. https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: Activating a device early during the boot process Use the zdev:early device attribute to activate a device early during the boot process and to override any existing auto-configuration with a persistent device configuration. zdev:early=1 The device is activated during the initial RAM disc phase according to the persistent configuration. zdev:early=0 The device is activated as usual during the boot process. This is the default. If auto-configuration data is present, the device is activated during the initial RAM disc phase according to the auto-configuration. I can't interprete a SCSI LUN as a device with auto configuration data. (At least, if the zfcp device hasn't NPIV enabled) == Comment: #5 - Peter Oberparleiter - 2023-03-01 11:18:28 == (In reply to comment #2) > @BOE-dev > This behaviour is unexpected. > https://www.ibm.com/docs/en/linux-on-systems?topic=commands-chzdev says: > Activating a device early during the boot process > > Use the zdev:early device attribute to activate a device early during the > boot process and to override any existing auto-configuration with a > persistent device configuration. > > zdev:early=1 > The device is activated during the initial RAM disc phase according to > the persistent configuration. > > zdev:early=0 > The device is activated as usual during the boot process. This is the > default. If auto-configuration data is present, the device is activated > during the initial RAM disc phase according to the auto-configuration. The documentation is incorrect for Ubuntu. Canonical specifically builds zdev in a way that every change to persistent device configuration causes an update to the initial RAM-disk. See also: https://bugzilla.linux.ibm.com/show_bug.cgi?id=187578#c35 https://github.com/ibm-s390-linux/s390-tools/commit/7dd03eaeecdd0e2674f145aca34be1275d291bd8 > I can't interprete a SCSI LUN as a device with auto configuration data. (At > least, if the zfcp device hasn't NPIV enabled) This is related to auto-configuration as implemented for DPM. == Comment: #6 - Thorsten Diehl - 2023-03-03 12:41:44 == So, IIUC, chzdev is built for Ubuntu with ZDEV_ALWAYS_UPDATE_INITRD=1, which make the parameter zdev:early=0 ineffective. Correct? If you confirm, you may also close this bug. Not nice - then we have to find an alternate solution. == Comment: #7 - Peter Oberparleiter - 2023-03-07 06:48:07 == (In reply to comment #6) > So, IIUC, chzdev is built for Ubuntu with
[Touch-packages] [Bug 2000430] Re: iwconfig shows implausible bitrate.
This issue is fixed on my current system with Ubuntu 23.10 `iwconfig Wireless-Tools version 30` wlp3s0IEEE 802.11 ESSID:"" Mode:Managed Frequency:5.18 GHz Access Point: Bit Rate=573.5 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=69/70 Signal level=-41 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:2 Invalid misc:234 Missed beacon:0 and another system wlp1s0IEEE 802.11 ESSID:"" Mode:Managed Frequency:5.18 GHz Access Point: Bit Rate=1.9215 Gb/s Tx-Power=22 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=63/70 Signal level=-47 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:3137 Missed beacon:0 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wireless-tools in Ubuntu. https://bugs.launchpad.net/bugs/2000430 Title: iwconfig shows implausible bitrate. Status in wireless-tools package in Ubuntu: Confirmed Bug description: When displaying connection info, `iwconfig` shows implausible information. wlp1s0IEEE 802.11 ESSID:"xx" Mode:Managed Frequency:5.24 GHz Access Point: 7E:45:58:xx:xx:xx Bit Rate=-1.89307e+06 kb/s Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=70/70 Signal level=-40 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:46 Invalid misc:15697 Missed beacon:0 while `iw` is fine Connected to 7e:45:58:xx:xx:xx (on wlp1s0) SSID: xx freq: 5240 RX: 2036803929 bytes (1776517 packets) TX: 100215785 bytes (575761 packets) signal: -41 dBm rx bitrate: 2161.3 MBit/s 160MHz HE-MCS 10 HE-NSS 2 HE-GI 0 HE-DCM 0 tx bitrate: 2401.9 MBit/s 160MHz HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0 bss flags: short-slot-time dtim period:3 beacon int: 100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wireless-tools/+bug/2000430/+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 1970069] Re: Annoying boot messages interfering with splash screen
Hmm, no plymouthd isn't starting quite early enough in Noble: 2.799s - plymouthd starts 4.080s - first show-splash attempt (rejected because DRM hasn't started yet) 5.290s - found /dev/dri/card0 5.364s - showing splash screen What this means is that any attempt to fix the bug in plymouthd itself (I was planning with FBIOPUT_CON2FBMAP) would be unreliable because plymouthd has started too late to dodge those early console messages. ** Changed in: plymouth (Ubuntu) Status: Confirmed => Invalid -- 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/1970069 Title: Annoying boot messages interfering with splash screen Status in linux package in Ubuntu: In Progress Status in plymouth package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: Since upgrading from 20.04.6 Desktop to 22.04, the boot screen is not as clean as it used to be. Basically, the flow used to be in 20.04: GRUB > Splash screen > Login prompt Currently in 22.04: GRUB > Splash screen > Messages (in the attached file) > Splash screen again for a sec > Login prompt All of those messages already existed in 20.04, the difference is that they were not appearing during boot. I was able to get rid of the "usb" related messages by just adding "loglevel=0" in GRUB. Currently is "quiet loglevel=0 splash". Regarding the fsck related message, I can get rid of them by adding "fsck.mode=skip". However, I do not want to just disable fsck or set the loglevel to 0. This is not a sustainable solution. Something definitely changed here. These messages are not of enough relevance to be shown at boot by default, and they should remain hidden like they were in Focal. Obviously a minor issue, but important to the whole look and feel of the OS for desktop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1970069/+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 2000430] Re: iwconfig shows implausible bitrate.
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: wireless-tools (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wireless-tools in Ubuntu. https://bugs.launchpad.net/bugs/2000430 Title: iwconfig shows implausible bitrate. Status in wireless-tools package in Ubuntu: Confirmed Bug description: When displaying connection info, `iwconfig` shows implausible information. wlp1s0IEEE 802.11 ESSID:"xx" Mode:Managed Frequency:5.24 GHz Access Point: 7E:45:58:xx:xx:xx Bit Rate=-1.89307e+06 kb/s Tx-Power=20 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=70/70 Signal level=-40 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:46 Invalid misc:15697 Missed beacon:0 while `iw` is fine Connected to 7e:45:58:xx:xx:xx (on wlp1s0) SSID: xx freq: 5240 RX: 2036803929 bytes (1776517 packets) TX: 100215785 bytes (575761 packets) signal: -41 dBm rx bitrate: 2161.3 MBit/s 160MHz HE-MCS 10 HE-NSS 2 HE-GI 0 HE-DCM 0 tx bitrate: 2401.9 MBit/s 160MHz HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0 bss flags: short-slot-time dtim period:3 beacon int: 100 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wireless-tools/+bug/2000430/+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 2045570] Re: dnsmasq crash when no servers in resolv.conf
** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2045570 Title: dnsmasq crash when no servers in resolv.conf Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: Fix Committed Bug description: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected. 1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803 The commit message says: """ This problem was introduced in 2.86. """ And indeed, I wasn't able to crash 2.80 shipped in focal. [ Test Plan ] It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. # Create a jammy lxd container lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 # Enter the container lxc shell j-dnsmasq-2045570 # From now on, all commands should be executed in the container. # Install dnsmasq, and disable systemd-resolved apt update && apt install -y dnsmasq # Disable systemd-resolved, and start dnsmasq systemctl disable --now systemd-resolved systemctl enable --now dnsmasq # In one terminal inside the container, watch the dnsmasq logs: journalctl -u dnsmasq.service -f # In another terminal, remove /etc/resolv.conf and create a new one, empty rm /etc/resolv.conf echo "nameserver 1.1.1.1" > /etc/resolv.conf # restart dnsmasq systemctl restart dnsmasq.service # Perform a dns query dig @127.0.0.1 +short linux.com # Comment the namserver directive in resolv.conf echo "#nameserver 1.1.1.1" > /etc/resolv.conf # Observe in the dnsmasq logs that it notices the change with a message like: Jan 03 14:14:51 j-dnsmasq-2045570 dnsmasq[2274]: no servers found in /etc/resolv.conf, will retry # Perform a *different* DNS query dig @127.0.0.1 +short ubuntu.com # Observe in the dnsmasq logs that it crashes. Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: - add "nameserver 127.0.0.1" to /etc/resolv.conf - observe that dnsmasq notices the change to the file - perform a query for some random domain using "dig @127.0.0.1 +short " - remove "nameserver" from /etc/resolv.conf, observe that dnsmasq noticed the change - perform a query for another random domain The fixed version from proposed will not crash. That last query with no "nameserver" lines in resolv.conf won't work, but it won't crash the server. [ Where problems could occur ] This is doing some pointer/memory manipulation that could introduce memory leaks or other crashes. In fact,
