[Touch-packages] [Bug 1941752] Re: Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening images exported by darktable
The attachment "1-0.27.2-8ubuntu2.7.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to exiv2 in Ubuntu. https://bugs.launchpad.net/bugs/1941752 Title: Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening images exported by darktable Status in Gwenview: Fix Released Status in exiv2 package in Ubuntu: Confirmed Status in gwenview package in Ubuntu: Confirmed Bug description: Since the recent security update of exiv2, Gwenview crashes when trying to open image files that got exported by darktable. Steps to reproduce: * Make a test installation of Kubuntu 21.04 in VirtualBox * Install all updates * Install darktable * Copy one of the images in /usr/share/wallpapers (or any other image) to your home directory and open it with darktable * Within darktable, export a copy of the image (no need to do any actual modifications) * Try to open that copy with Gwenview. Gwenview will crash. I'm attaching a crash report hinting that this is related to exiv2. Temporary workaround: If I downgrade libexiv2-27 to 0.27.3-3ubuntu1.4, Gwenview doesn't crash, so it seems the crash is related to changes in 0.27.3-3ubuntu1.5. I don't know if the underlying cause is actually some bug in exiv2, Gwenview or darktable. Kind regards, Jan ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: libexiv2-27 0.27.3-3ubuntu1.5 ProcVersionSignature: Ubuntu 5.11.0-31.33-generic 5.11.22 Uname: Linux 5.11.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Thu Aug 26 15:16:47 2021 InstallationDate: Installed on 2021-08-26 (0 days ago) InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: exiv2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gwenview/+bug/1941752/+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 1956062] [NEW] vim mis-manages modifyOtherKeys on xterms
Public bug reported: This began as question #76. I've observed odd behavior in vim since my upgrade from 18.04 to 20.04. One in particular is when I use the "r" command to replace a single character, shifted letters fail to work correctly and vim sputters and changes the case of letters in the line, instead of replace a single character. Another place is in search strings where I want to use the carriage-return character and type Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of "^M" and the search fails to do what I intended. Analyzing the problem in question #76 revealed this: When vim initializes (the xterm), it sends "^[[>4;2m" which sets the modifyOtherKeys=2 parameter. This appears to send *any* keys that use modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This explains why the un-shifted keys "r" and "s" appear normally. But, it appears that there are certain cases where vim is not properly interpreting the sequences that it requested. In the case of the "s" command, vim sends an "^[[>4;m" (modifyOtherKeys=0) before I can type the "A", so the "A" comes in as a normal ASCII character. It appears that vim should also be doing the same thing for "r" but does not. There are probably other contexts where vim is failing to properly manage the modifyOtherKeys setting, such as when I try ^V^M in search commands. In the case of the "r" command, vim sends no ESC sequences after the "r" so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses vim. In the case of search commands, vim is also failing to reset the modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences - although it appears that vim recognizes the ^V "^[[27;5;118~" and then (correctly) ignores the ESC in the ^M sequence "^[[27;5;109~". FYI, I understand that vim can now recognize "\r" in search strings, but that still leaves the problem of all the other control characters I must often manipulate in search commands. It is looking now as though there is actually a bug in vim, where it does not properly manage the modifyOtherKeys setting even though it explicitly requests that setting. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: vim 2:8.1.2269-1ubuntu5.4 ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151 Uname: Linux 5.4.0-91-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Thu Dec 30 15:49:03 2021 InstallationDate: Installed on 2017-02-22 (1772 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: vim UpgradeStatus: Upgraded to focal on 2020-10-04 (451 days ago) ** Affects: vim (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to vim in Ubuntu. https://bugs.launchpad.net/bugs/1956062 Title: vim mis-manages modifyOtherKeys on xterms Status in vim package in Ubuntu: New Bug description: This began as question #76. I've observed odd behavior in vim since my upgrade from 18.04 to 20.04. One in particular is when I use the "r" command to replace a single character, shifted letters fail to work correctly and vim sputters and changes the case of letters in the line, instead of replace a single character. Another place is in search strings where I want to use the carriage-return character and type Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of "^M" and the search fails to do what I intended. Analyzing the problem in question #76 revealed this: When vim initializes (the xterm), it sends "^[[>4;2m" which sets the modifyOtherKeys=2 parameter. This appears to send *any* keys that use modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This explains why the un-shifted keys "r" and "s" appear normally. But, it appears that there are certain cases where vim is not properly interpreting the sequences that it requested. In the case of the "s" command, vim sends an "^[[>4;m" (modifyOtherKeys=0) before I can type the "A", so the "A" comes in as a normal ASCII character. It appears that vim should also be doing the same thing for "r" but does not. There are probably other contexts where vim is failing to properly manage the modifyOtherKeys setting, such as when I try ^V^M in search commands. In the case of the "r" command, vim sends no ESC sequences after the "r" so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses vim. In the case of search commands, vim is also failing to reset the modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences - although it appears that vim recognizes the ^V "^[[27;5;118~" and then (correctly) ignores the ESC in the ^M sequence
[Touch-packages] [Bug 1941752] Re: Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening images exported by darktable
This is a debdiff applicable for focal-security. This backports an upstream fix for the regression introduced when fixing CVE-2021-37620. I build it locally in pbuilder and it fixes the crash in gwenview as expected. ** Patch added: "1-0.27.2-8ubuntu2.7.debdiff" https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1941752/+attachment/5550448/+files/1-0.27.2-8ubuntu2.7.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to exiv2 in Ubuntu. https://bugs.launchpad.net/bugs/1941752 Title: Regression: exiv2 0.27.3-3ubuntu1.5 makes Gwenview crash when opening images exported by darktable Status in Gwenview: Fix Released Status in exiv2 package in Ubuntu: Confirmed Status in gwenview package in Ubuntu: Confirmed Bug description: Since the recent security update of exiv2, Gwenview crashes when trying to open image files that got exported by darktable. Steps to reproduce: * Make a test installation of Kubuntu 21.04 in VirtualBox * Install all updates * Install darktable * Copy one of the images in /usr/share/wallpapers (or any other image) to your home directory and open it with darktable * Within darktable, export a copy of the image (no need to do any actual modifications) * Try to open that copy with Gwenview. Gwenview will crash. I'm attaching a crash report hinting that this is related to exiv2. Temporary workaround: If I downgrade libexiv2-27 to 0.27.3-3ubuntu1.4, Gwenview doesn't crash, so it seems the crash is related to changes in 0.27.3-3ubuntu1.5. I don't know if the underlying cause is actually some bug in exiv2, Gwenview or darktable. Kind regards, Jan ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: libexiv2-27 0.27.3-3ubuntu1.5 ProcVersionSignature: Ubuntu 5.11.0-31.33-generic 5.11.22 Uname: Linux 5.11.0-31-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Thu Aug 26 15:16:47 2021 InstallationDate: Installed on 2021-08-26 (0 days ago) InstallationMedia: Kubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) SourcePackage: exiv2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gwenview/+bug/1941752/+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 1769936] Re: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga 720
Hope this solution will be helpful for someone else https://forums.linuxmint.com/viewtopic.php?t=322530 -- 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/1769936 Title: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga 720 Status in alsa-driver package in Ubuntu: Confirmed Bug description: Happy to do further testing, fresh install of Bionic. Discovered this when trying to do a video conference using the built in mic and was able to verify the issue by installing gnome-sound-recorder. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: asif 2213 F...m pulseaudio /dev/snd/controlC0: asif 2213 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Tue May 8 11:58:37 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2018-04-28 (9 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH successful Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Mic, Internal Symptom_PulseAudioRecordingTest: PulseAudio recording test through plughw:PCH successful Symptom_Type: Digital clip or distortion, or "overdriven" sound Title: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/08/2018 dmi.bios.vendor: LENOVO dmi.bios.version: 4MCN31WW(V2.03) dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo YOGA 720-15IKB dmi.modalias: dmi:bvnLENOVO:bvr4MCN31WW(V2.03):bd03/08/2018:svnLENOVO:pn80X7:pvrLenovoYOGA720-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA720-15IKB: dmi.product.family: YOGA 720-15IKB dmi.product.name: 80X7 dmi.product.version: Lenovo YOGA 720-15IKB dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1769936/+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 1956029] Re: ufw remains inactive at boot time
Right after reboot I tried to get the status. Result is . . . . root@loki:~# s ufw status ERROR: problem running iptables: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? . . . . while fail2ban is setting up its rules. Anyway... After a reeboot, whatever I've done seems to have worked. I'm assuming adding "ufw.service" to fail2ban.service may have done the trick as has been mentioned on comment 4. -- 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/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
By networking stops means that I can not establish a connection with the Lemaker BananaPi Pro on any port so I can't get a SSHed shell, can't access the VPN server, etc... It behaves like someone has plugged the network cable. Putting "ufw.service" was a guess, but I've not rebooted the OS yet with that in place. root@loki:~# iptables --version iptables v1.8.4 (legacy) root@loki:~# uname -a Linux loki 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l armv7l armv7l GNU/Linux root@loki:~# fail2ban-client --version Fail2Ban v0.11.1 OS in use obtained from here: https://www.armbian.com/banana-pi-pro/ I will try a reboot and see what happens. Will report result back here. -- 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/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should
[Touch-packages] [Bug 574287] Re: tasksel: forcefully removes packages when tasks overlap
** Tags added: bionic focal hirsute impish jammy rls-jj-incoming xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/574287 Title: tasksel: forcefully removes packages when tasks overlap Status in apt package in Ubuntu: Invalid Status in tasksel package in Ubuntu: Confirmed Status in tasksel package in Debian: Fix Released Bug description: TEST CASE 1. Boot Lucid LiveCD 2. run "sudo tasksel" and select "virtual machine host" 3. run "sudo tasksel" and deselect "virtual machine host" 4. watch how tasksel uninstalls your system OBSERVATIONS What seems to happen is that apt vengefully removes ALL of the items associated with one task, including several base dependencies of other tasks (e.g. ubuntu-desktop) One illustrative example is the openssh-server task: This one includes the packages openssh-server, tcpd and libwrap0. From a normal ubuntu-desktop (e.g. ~liveCD) both tcpd and libwrap0 are already installed, and the task-install pulls in only openssh-server. However when the task is removed, all these three packages (openssh-server, tcpd and libwrap0) are forcefully removed. Since libwrap0 is a core dependency of gnome, a large part of gnome will be removed alongside the removal of the task. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/574287/+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 1769936] Re: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga 720
Any update for this? Use 20.04. Mic or doesn't work or make just a noise. -- 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/1769936 Title: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted Lenovo Yoga 720 Status in alsa-driver package in Ubuntu: Confirmed Bug description: Happy to do further testing, fresh install of Bionic. Discovered this when trying to do a video conference using the built in mic and was able to verify the issue by installing gnome-sound-recorder. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17 Uname: Linux 4.15.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/pcmC0D0p: asif 2213 F...m pulseaudio /dev/snd/controlC0: asif 2213 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Tue May 8 11:58:37 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2018-04-28 (9 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Symptom_AlsaRecordingTest: ALSA recording test through plughw:PCH successful Symptom_Card: Built-in Audio - HDA Intel PCH Symptom_Jack: Mic, Internal Symptom_PulseAudioRecordingTest: PulseAudio recording test through plughw:PCH successful Symptom_Type: Digital clip or distortion, or "overdriven" sound Title: [80X7, Realtek ALC236, Mic, Internal] Sound is distorted UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/08/2018 dmi.bios.vendor: LENOVO dmi.bios.version: 4MCN31WW(V2.03) dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo YOGA 720-15IKB dmi.modalias: dmi:bvnLENOVO:bvr4MCN31WW(V2.03):bd03/08/2018:svnLENOVO:pn80X7:pvrLenovoYOGA720-15IKB:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct31:cvrLenovoYOGA720-15IKB: dmi.product.family: YOGA 720-15IKB dmi.product.name: 80X7 dmi.product.version: Lenovo YOGA 720-15IKB dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1769936/+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 1956059] [NEW] Backport gspawn fixes to impish
Public bug reported: A few changes for gspawn landed in the 2.67 series that had some bugs which were later fixed and backported to 2.70 as seen in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2394. These bugs are present in 2.68 as on impish, but that series won't see any more updates upstream. Currently this is causing a bug in the OSTree test suite as seen in https://github.com/ostreedev/ostree/issues/2495 with https://github.com/ostreedev/ostree/issues/2495#issuecomment-1000247260 confirming from glib's maintainer that these bugs are likely the issue. Attached is a debdiff with the 3 patches that were backported to 2.70. ** Affects: glib2.0 (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Debdiff for 3 gspawn backport patches" https://bugs.launchpad.net/bugs/1956059/+attachment/5550436/+files/glib2.0_2.68.4-1ubuntu2.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1956059 Title: Backport gspawn fixes to impish Status in glib2.0 package in Ubuntu: New Bug description: A few changes for gspawn landed in the 2.67 series that had some bugs which were later fixed and backported to 2.70 as seen in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2394. These bugs are present in 2.68 as on impish, but that series won't see any more updates upstream. Currently this is causing a bug in the OSTree test suite as seen in https://github.com/ostreedev/ostree/issues/2495 with https://github.com/ostreedev/ostree/issues/2495#issuecomment-1000247260 confirming from glib's maintainer that these bugs are likely the issue. Attached is a debdiff with the 3 patches that were backported to 2.70. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1956059/+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 1956029] Re: ufw remains inactive at boot time
> How to I ensure that ufw is fully up and initialised BEFORE the
fail2ban service starts?
This line from your existing fail2ban.service should be sufficient:
After=network.target iptables.service firewalld.service
ip6tables.service ipset.service nftables.service ufw.service
See https://www.freedesktop.org/software/systemd/man/systemd.unit.html
for details ("After= is the inverse of Before=, i.e. while Before=
ensures that the configured unit is started before the listed unit
begins starting up, After= ensures the opposite, that the listed unit is
fully started up before the configured unit is started.")
--
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/1956029
Title:
ufw remains inactive at boot time
Status in ufw package in Ubuntu:
Incomplete
Bug description:
I was advised to start a bug report (Comment 38):
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856
I "ufw enable" then several seconds later networking stops. I have get
Ubuntu to gracefully power-down using the power-button and then
gracefully power-up.
Out of curiosity, is anyone here having this problem wish ufw starting
up at boot time while also using having fail2ban installed?
Here is my theory. It takes a while for fail2ban to issue all the
iptable commands to configure the firewall. When ufw tries to
initialise there may be a clash or lock held either by an iptables
instance spawned by fail2ban or an iptables instance spawned by ufw.
One of them will fail and will quite probably mess-up ufw's rules
breaking network connectivity.
This time I waited for fail2ban to finish establishing its iptables
rules before issuing "ufw enable" and this time round network
connectivity was not lost.
How to I ensure that ufw is fully up and initialised BEFORE the
fail2ban service starts?
-
root@loki:~# ./ufw-diag.sh
Has python: pass (binary: python3, version: 3.8.10, py3)
Has iptables: pass
Has ip6tables: pass
Has /proc/net/dev: pass
Has /proc/net/if_inet6: pass
This script will now attempt to create various rules using the iptables
and ip6tables commands. This may result in module autoloading (eg, for
IPv6).
Proceed with checks (Y/n)?
== IPv4 ==
Creating 'ufw-check-requirements'... done
Inserting RETURN at top of 'ufw-check-requirements'... done
TCP: pass
UDP: pass
destination port: pass
source port: pass
ACCEPT: pass
DROP: pass
REJECT: pass
LOG: pass
hashlimit: pass
limit: pass
ctstate (NEW): pass
ctstate (RELATED): pass
ctstate (ESTABLISHED): pass
ctstate (INVALID): pass
ctstate (new, recent set): pass
ctstate (new, recent update): pass
ctstate (new, limit): pass
interface (input): pass
interface (output): pass
multiport: pass
comment: pass
addrtype (LOCAL): pass
addrtype (MULTICAST): pass
addrtype (BROADCAST): pass
icmp (destination-unreachable): pass
icmp (source-quench): pass
icmp (time-exceeded): pass
icmp (parameter-problem): pass
icmp (echo-request): pass
== IPv6 ==
Creating 'ufw-check-requirements6'... done
Inserting RETURN at top of 'ufw-check-requirements6'... done
TCP: pass
UDP: pass
destination port: pass
source port: pass
ACCEPT: pass
DROP: pass
REJECT: pass
LOG: pass
hashlimit: pass
limit: pass
ctstate (NEW): pass
ctstate (RELATED): pass
ctstate (ESTABLISHED): pass
ctstate (INVALID): pass
ctstate (new, recent set): pass
ctstate (new, recent update): pass
ctstate (new, limit): pass
interface (input): pass
interface (output): pass
multiport: pass
comment: pass
icmpv6 (destination-unreachable): pass
icmpv6 (packet-too-big): pass
icmpv6 (time-exceeded): pass
icmpv6 (parameter-problem): pass
icmpv6 (echo-request): pass
icmpv6 with hl (neighbor-solicitation): pass
icmpv6 with hl (neighbor-advertisement): pass
icmpv6 with hl (router-solicitation): pass
icmpv6 with hl (router-advertisement): pass
ipv6 rt: pass
All tests passed
-
root@loki:/lib/systemd/system# cat ufw.service
[Unit]
Description=Uncomplicated firewall
Documentation=man:ufw(8)
DefaultDependencies=no
Before=network.target
After=NetworkManager.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/ufw/ufw-init start quiet
# ExecStartPost=/bin/sleep 10
ExecStop=/lib/ufw/ufw-init stop
[Install]
WantedBy=multi-user.target
-
root@loki:/lib/systemd/system# cat fail2ban.service
[Unit]
Description=Fail2Ban Service
Documentation=man:fail2ban(1)
After=network.target iptables.service firewalld.service ip6tables.service
ipset.service nftables.service ufw.service
PartOf=firewalld.service
[Service]
Type=simple
ExecStartPre=/bin/mkdir -p /run/fail2ban
ExecStart=/usr/bin/fail2ban-server -xf start
# if should be logged in systemd journal, use following line or set logtarget
to sysout in
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
> 4. you didn't mention which distro you are using This would be good to know since some distros are using iptables 1.8.x which has two different backends that are in play. Which distro are you using and what is the output of `iptables --version` -- 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/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
Thanks for the bug report. A few things: 1. I'm not sure what 'networking stops' means precisely in the context of this bug report. Does 'ufw disable' restore the network? Is the network torn down? Something else (you are using a lot of limit rules instead of allow rules, I wonder if you are hitting limits...)? 2. 'journalctl -u ufw.service' isn't normally going to show you much since the command run from the service isn't very chatty. Better would be to look at /var/log/ufw.log around the time the networking stops. If /var/log/ufw.log doesn't exist on your distro, you should check /var/log/kern.log for firewall denials and then try to resolve them with new/modified firewall rules 3. It isn't clear if you used the check-requirements from https://git.launchpad.net/ufw/tree/tests/check-requirements or the one on the system. Which did you use? (Note, I just made a change to https://git.launchpad.net/ufw/tree/tests/check-requirements that you might want to use) 4. you didn't mention which distro you are using, but the ufw.service file is not what is shipped upstream (or Ubuntu or Debian). This is what has been shipped in Ubuntu and Debian for several years: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target and this is what is upstream (Debian is the same except omits the 'Conflicts') and what should solve some issues (though I'm not sure it would solve your issues: [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) Before=network-pre.target Wants=network-pre.target Conflicts=iptables.service ip6tables.service nftables.service firewalld.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target You may want to adjust the service file to be like the upstream one, then run 'sudo systemctl daemon-reload' and reboot. ** Changed in: ufw (Ubuntu) Status: New => Incomplete -- 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/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: Incomplete Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT:
[Touch-packages] [Bug 1956043] Re: I need to stop my monitor scree from constant flicking
** Package changed: ubuntu => xorg (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1956043 Title: I need to stop my monitor scree from constant flicking Status in xorg package in Ubuntu: New Bug description: This PC was working normally, in May 17, 2021 at Kennedy Airport check-in for a trip to Panama Republic of Panama, I followed the commands of the security personnel to place computer and cell phones in a tray for examination.They examined my PC and two cell phone three times before returning them to me. After that examination session neither my PC nor cell phones could work. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.4.0-73.82~18.04.1-generic 5.4.106 Uname: Linux 5.4.0-73-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.27 Architecture: amd64 CompositorRunning: None Date: Thu Dec 30 08:17:43 2021 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu ExtraDebuggingInterest: No GraphicsCard: NVIDIA Corporation Device [10de:1f51] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:7510] MachineType: System76 Serval ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-73-generic root=UUID=d5244e1e-601c-42de-a015-225055a76c68 ro nvidia.NVreg_EnableBacklightHandler=1 quiet splash Renderer: Software SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/10/2019 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.05.25-1 dmi.board.asset.tag: Tag 12345 dmi.board.name: Serval dmi.board.vendor: System76 dmi.board.version: serw11 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: System76 dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.05.25-1:bd07/10/2019:svnSystem76:pnServal:pvrserw11:rvnSystem76:rnServal:rvrserw11:cvnSystem76:ct10:cvrN/A: dmi.product.family: Not Applicable dmi.product.name: Serval dmi.product.sku: Not Applicable dmi.product.version: serw11 dmi.sys.vendor: System76 version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.2 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.10 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Wed Dec 29 15:03:36 2021 xserver.configfile: default xserver.errors: [drm] Failed to open DRM device for pci::01:00.0: -19 open /dev/dri/card0: No such file or directory open /dev/dri/card0: No such file or directory Screen 0 deleted because of no matching config section. AIGLX: reverting to software rendering xserver.logfile: /var/log/Xorg.0.log xserver.outputs: xserver.version: 2:1.19.6-1ubuntu4.9 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1956043/+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 1956043] [NEW] I need to stop my monitor scree from constant flicking
You have been subscribed to a public bug: This PC was working normally, in May 17, 2021 at Kennedy Airport check- in for a trip to Panama Republic of Panama, I followed the commands of the security personnel to place computer and cell phones in a tray for examination.They examined my PC and two cell phone three times before returning them to me. After that examination session neither my PC nor cell phones could work. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.4.0-73.82~18.04.1-generic 5.4.106 Uname: Linux 5.4.0-73-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.27 Architecture: amd64 CompositorRunning: None Date: Thu Dec 30 08:17:43 2021 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu ExtraDebuggingInterest: No GraphicsCard: NVIDIA Corporation Device [10de:1f51] (rev a1) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device [1558:7510] MachineType: System76 Serval ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-73-generic root=UUID=d5244e1e-601c-42de-a015-225055a76c68 ro nvidia.NVreg_EnableBacklightHandler=1 quiet splash Renderer: Software SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/10/2019 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.05.25-1 dmi.board.asset.tag: Tag 12345 dmi.board.name: Serval dmi.board.vendor: System76 dmi.board.version: serw11 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: System76 dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.05.25-1:bd07/10/2019:svnSystem76:pnServal:pvrserw11:rvnSystem76:rnServal:rvrserw11:cvnSystem76:ct10:cvrN/A: dmi.product.family: Not Applicable dmi.product.name: Serval dmi.product.sku: Not Applicable dmi.product.version: serw11 dmi.sys.vendor: System76 version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.2 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.10 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Wed Dec 29 15:03:36 2021 xserver.configfile: default xserver.errors: [drm] Failed to open DRM device for pci::01:00.0: -19 open /dev/dri/card0: No such file or directory open /dev/dri/card0: No such file or directory Screen 0 deleted because of no matching config section. AIGLX: reverting to software rendering xserver.logfile: /var/log/Xorg.0.log xserver.outputs: xserver.version: 2:1.19.6-1ubuntu4.9 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ubuntu -- I need to stop my monitor scree from constant flicking https://bugs.launchpad.net/bugs/1956043 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg 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 1915238] Re: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
** Changed in: postfix (Debian) Status: Incomplete => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1915238 Title: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ Status in ca-certificates package in Ubuntu: Invalid Status in postfix package in Ubuntu: Triaged Status in postfix package in Debian: Fix Committed Bug description: Postfix package doesn't utilize update-ca-certificate's hooks mechanism. By simply copying certs from /etc/ssl/certs/ca- certificates.crt to /var/spool/postfix/etc/ssl/certs/ca- certificates.crt, this warning and potential security issues could be avoided. Something like this would be a start: $ cat /etc/ca-certificates/update.d/postfix #!/bin/bash if [ -e /var/spool/postfix/etc/ssl/certs/ca-certificates.crt ]; then echo "Updating postfix chrooted certs" cp /etc/ssl/certs/ca-certificates.crt /var/spool/postfix/etc/ssl/certs/ca-certificates.crt systemctl reload postfix fi To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1915238/+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 1956029] Re: ufw remains inactive at boot time
root@loki:/home/myron# journalctl -u ufw.service -- Logs begin at Wed 2021-12-29 15:30:45 GMT, end at Thu 2021-12-30 13:10:27 GMT. -- -- No entries -- - Current status of service. ufw was enabled manually so is actually active. It won't be once I reboot. root@loki:/home/myron# systemctl status ufw ● ufw.service - Uncomplicated firewall Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled) Active: active (exited) since Wed 2021-12-29 15:30:34 GMT; 21h ago Docs: man:ufw(8) Main PID: 295 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) Memory: 0B CGroup: /system.slice/ufw.service Warning: journal has been rotated since unit was started, output may be incomplete. -- 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/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: New Bug description: I was advised to start a bug report (Comment 38): https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban
[Touch-packages] [Bug 1956029] Re: ufw remains inactive at boot time
** Description changed: - I was advised to start a bug report: - https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38 + I was advised to start a bug report (Comment 38): + https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw # # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback # accepted). You will need to 'disable' and then 'enable' the firewall for # the changes to take affect. IPV6=yes # Set the default input policy to ACCEPT, DROP, or REJECT. Please note that if # you change this you will most likely want to adjust your rules.
[Touch-packages] [Bug 1939455] Re: Upgrading from 20.0.4-2ubuntu1 to 21.0.3-0ubuntu0.2~20.04.1 breaks vlc video output
For the benefit of others I had a similar problem with Kaffeine 2.0.18 on Lubuntu 20.04.3, no video with DVB-T broadcast and only audio working. The upgrade to 21.0.3 broke a system that was stable for about a year. Also Kaffeine will crash changing channels. Running Kaffeine from command prompt shows unable to decode video messages type messages. Finally tracked down this ticket and down leveling to 20.0.4 solved problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1939455 Title: Upgrading from 20.0.4-2ubuntu1 to 21.0.3-0ubuntu0.2~20.04.1 breaks vlc video output Status in mesa package in Ubuntu: New Bug description: Hello! As reported here https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1939447 upgrading mesa-vdpau-drivers package from 20.0.4-2ubuntu1 to 21.0.3-0ubuntu0.2~20.04.1 breaks vlc video hardware acceleration. Thanks! ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: mesa-vdpau-drivers 21.0.3-0ubuntu0.2~20.04.1 ProcVersionSignature: Ubuntu 5.4.0-80.90-generic 5.4.124 Uname: Linux 5.4.0-80-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: XFCE Date: Wed Aug 11 02:21:08 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics] [1002:9851] (rev 40) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Mullins [Radeon R4/R5 Graphics] [103c:81e5] MachineType: HP HP 245 G5 Notebook PC ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-80-generic root=UUID=e8820090-c9e5-4245-bcb4-92818bd91e34 ro quiet splash vt.handoff=7 SourcePackage: mesa UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/21/2016 dmi.bios.vendor: Insyde dmi.bios.version: F.08 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: 81E5 dmi.board.vendor: HP dmi.board.version: KBC Version 73.14 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnInsyde:bvrF.08:bd04/21/2016:svnHP:pnHP245G5NotebookPC:pvrType1ProductConfigId:rvnHP:rn81E5:rvrKBCVersion73.14:cvnHP:ct10:cvrChassisVersion: dmi.product.family: 103C_5336AN G=N L=SMB B=HP S=245 dmi.product.name: HP 245 G5 Notebook PC dmi.product.sku: Y9Q66PC#ACJ dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP modified.conffile..etc.default.apport: # set this to 0 to disable apport, or to 1 to enable it # you can temporarily override this with # sudo service apport start force_start=1 enabled=0 mtime.conffile..etc.default.apport: 2020-08-12T15:11:08.785042 version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.105-3~20.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 21.0.3-0ubuntu0.2~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.11-1ubuntu1~20.04.2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1939455/+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 1956039] [NEW] BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018)
Public bug reported: Updating Jammy fails with: Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB] Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1956039 Title: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) Status in apt package in Ubuntu: New Bug description: Updating Jammy fails with: Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB] Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1956039/+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 1726856] Re: ufw does not start automatically at boot
@jdstrand I've created a new bug report as you suggested: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1956029 -- 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/1726856 Title: ufw does not start automatically at boot Status in ufw: Invalid Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Xenial: Invalid Status in ufw source package in Bionic: Invalid Status in ufw source package in Cosmic: Invalid Status in ufw source package in Disco: Invalid Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1956029] Re: ufw remains inactive at boot time
** Summary changed: - ufw does not activate at boot time + ufw remains inactive at boot time -- 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/1956029 Title: ufw remains inactive at boot time Status in ufw package in Ubuntu: New Bug description: I was advised to start a bug report: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw # # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback # accepted). You will need to 'disable' and then 'enable' the firewall for #
[Touch-packages] [Bug 1956029] [NEW] ufw does not activate at boot time
Public bug reported: I was advised to start a bug report: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/comments/38 I "ufw enable" then several seconds later networking stops. I have get Ubuntu to gracefully power-down using the power-button and then gracefully power-up. Out of curiosity, is anyone here having this problem wish ufw starting up at boot time while also using having fail2ban installed? Here is my theory. It takes a while for fail2ban to issue all the iptable commands to configure the firewall. When ufw tries to initialise there may be a clash or lock held either by an iptables instance spawned by fail2ban or an iptables instance spawned by ufw. One of them will fail and will quite probably mess-up ufw's rules breaking network connectivity. This time I waited for fail2ban to finish establishing its iptables rules before issuing "ufw enable" and this time round network connectivity was not lost. How to I ensure that ufw is fully up and initialised BEFORE the fail2ban service starts? - root@loki:~# ./ufw-diag.sh Has python: pass (binary: python3, version: 3.8.10, py3) Has iptables: pass Has ip6tables: pass Has /proc/net/dev: pass Has /proc/net/if_inet6: pass This script will now attempt to create various rules using the iptables and ip6tables commands. This may result in module autoloading (eg, for IPv6). Proceed with checks (Y/n)? == IPv4 == Creating 'ufw-check-requirements'... done Inserting RETURN at top of 'ufw-check-requirements'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass addrtype (LOCAL): pass addrtype (MULTICAST): pass addrtype (BROADCAST): pass icmp (destination-unreachable): pass icmp (source-quench): pass icmp (time-exceeded): pass icmp (parameter-problem): pass icmp (echo-request): pass == IPv6 == Creating 'ufw-check-requirements6'... done Inserting RETURN at top of 'ufw-check-requirements6'... done TCP: pass UDP: pass destination port: pass source port: pass ACCEPT: pass DROP: pass REJECT: pass LOG: pass hashlimit: pass limit: pass ctstate (NEW): pass ctstate (RELATED): pass ctstate (ESTABLISHED): pass ctstate (INVALID): pass ctstate (new, recent set): pass ctstate (new, recent update): pass ctstate (new, limit): pass interface (input): pass interface (output): pass multiport: pass comment: pass icmpv6 (destination-unreachable): pass icmpv6 (packet-too-big): pass icmpv6 (time-exceeded): pass icmpv6 (parameter-problem): pass icmpv6 (echo-request): pass icmpv6 with hl (neighbor-solicitation): pass icmpv6 with hl (neighbor-advertisement): pass icmpv6 with hl (router-solicitation): pass icmpv6 with hl (router-advertisement): pass ipv6 rt: pass All tests passed - root@loki:/lib/systemd/system# cat ufw.service [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no Before=network.target After=NetworkManager.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet # ExecStartPost=/bin/sleep 10 ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target - root@loki:/lib/systemd/system# cat fail2ban.service [Unit] Description=Fail2Ban Service Documentation=man:fail2ban(1) After=network.target iptables.service firewalld.service ip6tables.service ipset.service nftables.service ufw.service PartOf=firewalld.service [Service] Type=simple ExecStartPre=/bin/mkdir -p /run/fail2ban ExecStart=/usr/bin/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=/usr/bin/fail2ban-server -xf --logtarget=sysout start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 [Install] WantedBy=multi-user.target - root@loki:/etc/default# cat ufw # /etc/default/ufw # # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback # accepted). You will need to 'disable' and then 'enable' the firewall for # the changes to take affect. IPV6=yes # Set the default input policy to ACCEPT, DROP, or REJECT. Please note that if # you change this you will most likely want to adjust your rules. DEFAULT_INPUT_POLICY="DROP" # Set the default output policy to ACCEPT, DROP, or REJECT. Please note that if # you change this you will most likely want to adjust your rules. DEFAULT_OUTPUT_POLICY="ACCEPT" # Set the default forward policy to ACCEPT, DROP or REJECT. Please note that # if you change this you will most likely want to adjust your rules DEFAULT_FORWARD_POLICY="DROP" # Set the default application policy to ACCEPT, DROP, REJECT
