[Touch-packages] [Bug 2062126] [NEW] Booting with laptop lid closed and external monitors on X11 causes the computer to sleep prior to login
Public bug reported: When powering on a laptop with the lid closed, connected to a dock which is connected to external monitors, if gdm3 is going to run on X11, the computer is suspended prior to the login screen being displayed. Tapping a key on the keyboard wakes the computer out of suspend and immediately shows the login screen on the external monitors as expected. The computer does not suspend prior to login if gdm3 is going to run on Wayland. I'm encountering this issue with Ubuntu 24.04 beta, and believe it may be related to the following systemd issue: https://github.com/systemd/systemd/issues/16045 ** Affects: systemd (Ubuntu) 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/2062126 Title: Booting with laptop lid closed and external monitors on X11 causes the computer to sleep prior to login Status in systemd package in Ubuntu: New Bug description: When powering on a laptop with the lid closed, connected to a dock which is connected to external monitors, if gdm3 is going to run on X11, the computer is suspended prior to the login screen being displayed. Tapping a key on the keyboard wakes the computer out of suspend and immediately shows the login screen on the external monitors as expected. The computer does not suspend prior to login if gdm3 is going to run on Wayland. I'm encountering this issue with Ubuntu 24.04 beta, and believe it may be related to the following systemd issue: https://github.com/systemd/systemd/issues/16045 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2062126/+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 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
Note that after this fix, snapd in containers needs to be at >= 2.62 for
apparmor policy to load (snapd's snapd-apparmor needs the corresponding
fix as this bug). This is currently in the candidate channel.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2060535
Title:
apparmor's is_container_with_internal_policy() does not recognize
incus
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Bionic:
Triaged
Status in apparmor source package in Focal:
Triaged
Status in apparmor source package in Jammy:
Triaged
Status in apparmor source package in Noble:
Fix Released
Bug description:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
is_container_with_internal_policy() {
# this function is sometimes called independently of
# is_apparmor_loaded(), so also define this here.
local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
local ns_stacked
local ns_name
if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
return 1
fi
read -r ns_stacked < "$ns_stacked_path"
if [ "$ns_stacked" != "yes" ]; then
return 1
fi
# LXD and LXC set up AppArmor namespaces starting with "lxd-" and
# "lxc-", respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ]; then
return 1
fi
return 0
}
This can be fixed by adjusting it to have:
# LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
# "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ] && \
[ "${ns_name#incus-*}" = "$ns_name" ] ; then
return 1
fi
References:
* https://github.com/lxc/incus/issues/740
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+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 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
This is already available in noble. An SRU for jammy and focal (and
ideally bionic) would be nice.
** Changed in: apparmor (Ubuntu Bionic)
Status: New => Triaged
** Changed in: apparmor (Ubuntu Focal)
Status: New => Triaged
** Changed in: apparmor (Ubuntu Jammy)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2060535
Title:
apparmor's is_container_with_internal_policy() does not recognize
incus
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Bionic:
Triaged
Status in apparmor source package in Focal:
Triaged
Status in apparmor source package in Jammy:
Triaged
Status in apparmor source package in Noble:
Fix Released
Bug description:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
is_container_with_internal_policy() {
# this function is sometimes called independently of
# is_apparmor_loaded(), so also define this here.
local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
local ns_stacked
local ns_name
if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
return 1
fi
read -r ns_stacked < "$ns_stacked_path"
if [ "$ns_stacked" != "yes" ]; then
return 1
fi
# LXD and LXC set up AppArmor namespaces starting with "lxd-" and
# "lxc-", respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ]; then
return 1
fi
return 0
}
This can be fixed by adjusting it to have:
# LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
# "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ] && \
[ "${ns_name#incus-*}" = "$ns_name" ] ; then
return 1
fi
References:
* https://github.com/lxc/incus/issues/740
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+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 2060535] Re: apparmor's is_container_with_internal_policy() does not recognize incus
https://gitlab.com/apparmor/apparmor/-/commit/659a187687fc8802045c113da0d12bc4b836d591
was committed upstream for this. It would be nice if this was SRU'd.
** Changed in: apparmor (Ubuntu Noble)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2060535
Title:
apparmor's is_container_with_internal_policy() does not recognize
incus
Status in apparmor package in Ubuntu:
Fix Released
Status in apparmor source package in Bionic:
Triaged
Status in apparmor source package in Focal:
Triaged
Status in apparmor source package in Jammy:
Triaged
Status in apparmor source package in Noble:
Fix Released
Bug description:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
is_container_with_internal_policy() {
# this function is sometimes called independently of
# is_apparmor_loaded(), so also define this here.
local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
local ns_stacked
local ns_name
if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
return 1
fi
read -r ns_stacked < "$ns_stacked_path"
if [ "$ns_stacked" != "yes" ]; then
return 1
fi
# LXD and LXC set up AppArmor namespaces starting with "lxd-" and
# "lxc-", respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ]; then
return 1
fi
return 0
}
This can be fixed by adjusting it to have:
# LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
# "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ] && \
[ "${ns_name#incus-*}" = "$ns_name" ] ; then
return 1
fi
References:
* https://github.com/lxc/incus/issues/740
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2060535/+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 2060535] [NEW] apparmor's is_container_with_internal_policy() does not recognize incus
Public bug reported:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
is_container_with_internal_policy() {
# this function is sometimes called independently of
# is_apparmor_loaded(), so also define this here.
local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
local ns_stacked
local ns_name
if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
return 1
fi
read -r ns_stacked < "$ns_stacked_path"
if [ "$ns_stacked" != "yes" ]; then
return 1
fi
# LXD and LXC set up AppArmor namespaces starting with "lxd-" and
# "lxc-", respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ]; then
return 1
fi
return 0
}
This can be fixed by adjusting it to have:
# LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
# "lxc-", and "incus-" respectively. Return non-zero for all other namespace
# identifiers.
read -r ns_name < "$ns_name_path"
if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
[ "${ns_name#lxc-*}" = "$ns_name" ] && \
[ "${ns_name#incus-*}" = "$ns_name" ] ; then
return 1
fi
References:
* https://github.com/lxc/incus/issues/740
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Bionic)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Focal)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Jammy)
Importance: Undecided
Status: New
** Affects: apparmor (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Noble)
Importance: Undecided
Status: New
** Also affects: apparmor (Ubuntu Jammy)
Importance: Undecided
Status: New
** Description changed:
apparmor is not loading for Ubuntu containers under incus. This is due
to `/lib/apparmor/rc.apparmor.functions` (18.04 uses
`/lib/apparmor/functions`):
+ is_container_with_internal_policy() {
+ # this function is sometimes called independently of
+ # is_apparmor_loaded(), so also define this here.
+ local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
+ local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
+ local ns_stacked
+ local ns_name
- is_container_with_internal_policy() {
- # this function is sometimes called independently of
- # is_apparmor_loaded(), so also define this here.
- local ns_stacked_path="${SFS_MOUNTPOINT}/.ns_stacked"
- local ns_name_path="${SFS_MOUNTPOINT}/.ns_name"
- local ns_stacked
- local ns_name
+ if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
+ return 1
+ fi
- if ! [ -f "$ns_stacked_path" ] || ! [ -f "$ns_name_path" ]; then
- return 1
- fi
+ read -r ns_stacked < "$ns_stacked_path"
+ if [ "$ns_stacked" != "yes" ]; then
+ return 1
+ fi
- read -r ns_stacked < "$ns_stacked_path"
- if [ "$ns_stacked" != "yes" ]; then
- return 1
- fi
+ # LXD and LXC set up AppArmor namespaces starting with "lxd-" and
+ # "lxc-", respectively. Return non-zero for all other namespace
+ # identifiers.
+ read -r ns_name < "$ns_name_path"
+ if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
+[ "${ns_name#lxc-*}" = "$ns_name" ]; then
+ return 1
+ fi
- # LXD and LXC set up AppArmor namespaces starting with "lxd-" and
- # "lxc-", respectively. Return non-zero for all other namespace
- # identifiers.
- read -r ns_name < "$ns_name_path"
- if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
- [ "${ns_name#lxc-*}" = "$ns_name" ]; then
- return 1
- fi
-
- return 0
+ return 0
}
- ```
This can be fixed by adjusting it to have:
- ```
- # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
- # "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
- # identifiers.
- read -r ns_name < "$ns_name_path"
- if [ "${ns_name#lxd-*}" = "$ns_name" ] && \
- [ "${ns_name#lxc-*}" = "$ns_name" ] && \
- [ "${ns_name#incus-*}" = "$ns_name" ] ; then
- return 1
- fi
- return 0
+ # LXD, LXC and incus set up AppArmor namespaces starting with "lxd-",
+ # "lxc-", and "incus-" respectively. Return non-zero for all other
namespace
+ # identifiers.
+ read -r ns_name < "$ns_name_path"
+
[Touch-packages] [Bug 2051540] Re: ufw ftbfs with Python 3.12 as default
Ok, https://autopkgtest.ubuntu.com/results/autopkgtest-
noble/noble/amd64/u/ufw/20240211_163608_4a05d@/log.gz (the one for
python3-defaults/3.12.1-0ubuntu1) passed with 0.36.2-4 so hopefully this
bug will stay closed! :)
--
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:
Fix Released
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
> From my reading (https://github.com/pypa/setuptools/issues/3661),
installing python3-setuptools instead of python3-distutils should be
sufficient, with a new enough setuptools, which we have in noble.
Uploaded 0.36.2-4 to unstable, it migrated to noble-proposed and
awaiting autopkgtests.
--
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 2051540] Re: ufw ftbfs with Python 3.12 as default
>From my reading (https://github.com/pypa/setuptools/issues/3661),
installing python3-setuptools instead of python3-distutils should be
sufficient, with a new enough setuptools, which we have in noble.
** Bug watch added: github.com/pypa/setuptools/issues #3661
https://github.com/pypa/setuptools/issues/3661
--
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 2051540] Re: ufw ftbfs with Python 3.12 as default
I can also reproduce if I have python3-setuptools installed, but don't
have python3-distutils installed and use
SETUPTOOLS_USE_DISTUTILS=stdlib.
--
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 2051540] Re: ufw ftbfs with Python 3.12 as default
Mathias,
So, this is a little hard to fix with the archive packages now and I'm
not sure where people are going with the 3.12 updates. I can get
python3.12 reasonably easily enough but debian/tests/control has:
# root unittests under python3
Tests: root-unittest
Depends: iptables,
netbase,
procps,
sed,
python3,
python3-distutils
Restrictions: needs-root, allow-stderr, isolation-machine, build-needed,
rw-build-tree
# unittests under python3
Tests: unittest
Depends: iptables,
netbase,
procps,
sed,
python3,
python3-distutils,
dh-python,
Both of these are installing python3-distutils, but only one is
installing dh-python. dh-python depends on both python3-distutils and
python3-setuptools. Presumably dh-python is going to stop installing
python3-distutils? However, python3-setuptools *also* depends on
python3-distutils (which the setuptools package provides).
As it stands, ufw 0.36.2-3 builds fine with what is in noble now and
should in what is in noble-proposed now (indeed, it passed its
autopkgtests and migrated recently).
Where was this test result coming from? What is the goal of that build?
Since the autopkgtests are declaring that python3-distutils be
installed, we shouldn't be getting the the error since it should be
there.
I can create an artificial situation and do 'sudo dpkg --force-depends
--purge python3-distutils' (but is this even valid?) but even in that
situation, python3-setuptools in the archive being installed still
allows the import to work. Only if I do 'sudo dpkg --force-depends
--purge python3-distutils python3-setuptools' can I reproduce the import
error, but the fix is to use python3-setuptools
--
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 2051540] Re: ufw ftbfs with Python 3.12 as default
fyi, I plan to fix this but probably not til next week. My plan is to
adjst the import to conditionally (or fall back to) import
setuptools.distutil and then adjust the Build-Depends/autopkgtests to
specify python3-setuptools.
I may do something else longer term, but that should get things going
again.
--
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 2051540] Re: ufw ftbfs with Python 3.12 as default
https://launchpad.net/ubuntu/+source/ufw/0.36.2-3/+build/27739360 built
fine. Closing.
** Changed in: ufw (Ubuntu)
Status: Confirmed => 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:
Fix Released
Status in ufw package in Debian:
New
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
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 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
Verified on 22.04 using util-linux=2.37.2-4ubuntu3.2 $ apt policy util-linux util-linux: Installed: 2.37.2-4ubuntu3.2 Candidate: 2.37.2-4ubuntu3.2 Version table: *** 2.37.2-4ubuntu3.2 500 500 http://ports.ubuntu.com/ubuntu-ports jammy-proposed/main arm64 Packages 100 /var/lib/dpkg/status 2.37.2-4ubuntu3 500 500 http://ports.ubuntu.com/ubuntu-ports jammy/main arm64 Packages $ lscpu | head -n10 Architecture: aarch64 CPU op-mode(s): 64-bit Byte Order: Little Endian CPU(s): 288 On-line CPU(s) list:0-287 Vendor ID: ARM Model name: Neoverse-V2 Model: 0 Thread(s) per core: 1 Core(s) per socket: 72 -- 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 2047286] [NEW] package perl-modules-5.34 5.34.0-3ubuntu1.2 failed to install/upgrade: unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be ins
Public bug reported: Cant install or update Ubuntu Server ProblemType: Package DistroRelease: Ubuntu 22.04 Package: perl-modules-5.34 5.34.0-3ubuntu1.2 ProcVersionSignature: Ubuntu 5.15.0-88.98-generic 5.15.126 Uname: Linux 5.15.0-88-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 AptOrdering: perl-modules-5.34:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Sat Dec 23 16:38:27 2023 DpkgTerminalLog: Preparing to unpack .../perl-modules-5.34_5.34.0-3ubuntu1.3_all.deb ... Unpacking perl-modules-5.34 (5.34.0-3ubuntu1.3) over (5.34.0-3ubuntu1.2) ... [1mdpkg:[0m error processing archive /var/cache/apt/archives/perl-modules-5.34_5.34.0-3ubuntu1.3_all.deb (--unpack): unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message ErrorMessage: unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message InstallationDate: Installed on 2023-05-10 (227 days ago) InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230217.1) PackageArchitecture: all Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 3.10.6-1~22.04 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.1ubuntu2.2 apt 2.4.11 SourcePackage: perl Title: package perl-modules-5.34 5.34.0-3ubuntu1.2 failed to install/upgrade: unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: perl (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package jammy uec-images -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/2047286 Title: package perl-modules-5.34 5.34.0-3ubuntu1.2 failed to install/upgrade: unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message Status in perl package in Ubuntu: New Bug description: Cant install or update Ubuntu Server ProblemType: Package DistroRelease: Ubuntu 22.04 Package: perl-modules-5.34 5.34.0-3ubuntu1.2 ProcVersionSignature: Ubuntu 5.15.0-88.98-generic 5.15.126 Uname: Linux 5.15.0-88-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 AptOrdering: perl-modules-5.34:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Sat Dec 23 16:38:27 2023 DpkgTerminalLog: Preparing to unpack .../perl-modules-5.34_5.34.0-3ubuntu1.3_all.deb ... Unpacking perl-modules-5.34 (5.34.0-3ubuntu1.3) over (5.34.0-3ubuntu1.2) ... [1mdpkg:[0m error processing archive /var/cache/apt/archives/perl-modules-5.34_5.34.0-3ubuntu1.3_all.deb (--unpack): unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message ErrorMessage: unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message InstallationDate: Installed on 2023-05-10 (227 days ago) InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230217.1) PackageArchitecture: all Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 3.10.6-1~22.04 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.1ubuntu2.2 apt 2.4.11 SourcePackage: perl Title: package perl-modules-5.34 5.34.0-3ubuntu1.2 failed to install/upgrade: unable to stat './usr/share/perl/5.34.0/unicore/lib/ExtPict/Y.pl' (which was about to be installed): Bad message UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/2047286/+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 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
> If you are using NetworkManager, then systemd-networkd.service (and associated units like systemd-networkd-wait-online.service) should NOT be enabled. With the caveat that I am not sure why you have systemd- networkd enabled in the first place, I would recommend that you simply disable it: > $ systemctl disable --now systemd-networkd.service > This will also have the effect of disabling systemd-networkd-wait- online.service. Ok, I've done this. It is easy enough to re-enable if I need to test anything wrt the bug. This resolved the issue for 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+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 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
>> On Ubuntu 22.04 desktop system using network-manager > To be clear, does this mean you have no network interfaces that are configured to use networkd? Hey Steve :) So, this system is quite old. I think the first install was 16.04 and it went through a bunch of upgrades (mostly interim until 20.04 and then to 22.04). It would not surprise me if things weren't pristine. I'll give some info and you can tell me what else to provide: $ cat /etc/netplan/01-network-manager-all.yaml # Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager $ sudo netplan get all network: version: 2 renderer: NetworkManager $ ls /etc/systemd/network $ $ cat /etc/systemd/networkd.conf # This file is part of systemd. ... # See networkd.conf(5) for details. [Network] #SpeedMeter=no #SpeedMeterIntervalSec=10sec #ManageForeignRoutingPolicyRules=yes #ManageForeignRoutes=yes #RouteTable= [DHCPv4] #DUIDType=vendor #DUIDRawData= [DHCPv6] #DUIDType=vendor #DUIDRawData= $ sudo systemctl status systemd-networkd ● systemd-networkd.service - Network Configuration Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2023-09-17 12:13:48 CDT; 1 day 2h ago TriggeredBy: ● systemd-networkd.socket Docs: man:systemd-networkd.service(8) Main PID: 1442 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 18857) Memory: 2.7M CPU: 1.387s CGroup: /system.slice/systemd-networkd.service └─1442 /lib/systemd/systemd-networkd Sep 17 14:33:42 systemd-networkd[1442]: wlp58s0: Lost carrier Sep 17 14:33:43 systemd-networkd[1442]: wlp58s0: Gained carrier Sep 17 16:44:57 systemd-networkd[1442]: lxd0: Link UP Sep 17 16:45:02 systemd-networkd[1442]: veth8afa41ff: Link UP Sep 17 16:45:02 systemd-networkd[1442]: veth8afa41ff: Gained carrier Sep 17 16:45:02 systemd-networkd[1442]: lxd0: Gained carrier Sep 17 16:45:02 systemd-networkd[1442]: lxd0: Gained IPv6LL Sep 17 17:32:49 systemd-networkd[1442]: wlp58s0: Lost carrier Sep 17 17:32:50 systemd-networkd[1442]: wlp58s0: Connected WiFi access point: () Sep 17 17:32:50 systemd-networkd[1442]: wlp58s0: Gained carrier I don't recall enabling systemd-networkd, but a lot has happened over the last 7 years, 4.5 of those while developing Ubuntu. :) -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: Confirmed Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+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 2036358] Re: systemd wait-online now times out after jammy and lunar upgrade
** Description changed: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents - logins (GDM, ssh, console) until it does. This seems to be introduced by - the change for + logins (GDM, ssh, console) until it does time out. This seems to be + introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: New Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does time out. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+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 2036358] [NEW] systemd wait-online now times out after jammy and lunar upgrade
Public bug reported: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: regression-update ** Description changed: On Ubuntu 22.04 and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 - also mentioned the problem. + also mentioned the problem on Lunar. ** Description changed: - On Ubuntu 22.04 and upgrading to systemd 249.11-0ubuntu3.10, wait-online - now times out which prevents logins (GDM, ssh, console) until it does. - This seems to be introduced by the change for + On Ubuntu 22.04 desktop system using network-manager and upgrading to + systemd 249.11-0ubuntu3.10, wait-online now times out which prevents + logins (GDM, ssh, console) until it does. This seems to be introduced by + the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. ** Summary changed: - systemd 249.11-0ubuntu3.10 wait-online now times out after upgrade + systemd wait-online now times out after jammy and lunar upgrade ** Tags added: regression-update -- 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/2036358 Title: systemd wait-online now times out after jammy and lunar upgrade Status in systemd package in Ubuntu: New Bug description: On Ubuntu 22.04 desktop system using network-manager and upgrading to systemd 249.11-0ubuntu3.10, wait-online now times out which prevents logins (GDM, ssh, console) until it does. This seems to be introduced by the change for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/comments/21 also mentioned the problem on Lunar. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358/+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 1982218] Re: wait-online does not correctly identify managed links
> Somehow, wait-online now times out, while it didn't before this update. I just created https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358 to track this. -- 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/1982218 Title: wait-online does not correctly identify managed links Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Released Status in systemd source package in Lunar: Fix Released Bug description: [Impact] systemd-networkd-wait-online will exit prematurely when the --any flag is passed, due to an incorrect patch in Ubuntu that is supposed to make systemd-networkd-wait-online exit when *no* links are managed. [Test Plan] This test uses a VM managed by libvirt. In this scenario we have the "default" network which provides DHCP to the VM, and the "no-dhcp" network which does not provide DHCP. To setup the VM (this assumes Jammy, but the same steps apply for Lunar using appropriate names and install media): 1. Define the default and no-dhcp networks: $ cat > /tmp/net-default.xml << EOF default 04260896-2701-422d-84e0-8e0df1122db3 $ virsh net-create --file /tmp/net-default.xml $ cat > /tmp/net-default.xml << EOF no-dhcp 2c047740-caab-4c90-8421-70da6732a759 $ virsh net-create --file /tmp/net-no-dhcp.xml $ virsh net-start --network default $ virst net-start --network no-dhcp 2. Create the VM using virt-install: virt-install \ --connect=qemu:///system \ --name=jammy \ --arch=x86_64 \ --cpu=host-passthrough \ --ram=4096 \ --vcpus=1 \ --disk=path=/var/lib/libvirt/images/jammy.qcow2,size=24,format=qcow2,sparse=true,bus=virtio \ --virt-type=kvm \ --accelerate \ --hvm \ --cdrom=/tmp/ubuntu-22.04.2-live-server-amd64.iso \ --os-type=linux \ --os-variant=generic \ --graphics=spice \ --input=tablet \ --network=network=default,model=virtio \ --video=qxl \ --noreboot 3. Complete the installation steps. Reboot the VM. Run the test: 1. Detach the network interface so that the test starts with no interfaces attached: $ virsh detach-interface $VM network 2. In the VM, write a network config for all en* links to use DHCP: $ cat > /etc/systemd/network/10-dhcp.network << EOF [Match] Name=en* [Network] DHCP=yes EOF 3. Restart systemd-networkd: $ systemctl restart systemd-networkd 4. On the host, attach an interface to the VM on the no-dhcp network, so that an IP is not assigned: $ virsh attach-interface $VM network no-dhcp 5. Back in the VM, confirm that the device is in the degraded/configuring state: $ networkctl networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 2 links listed. 6. Run systemd-networkd-wait-online --any, and confirm that it does timeout instead of returning while the device is is still not configured: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=10 Timeout occurred while waiting for network connectivity. 7. Confirm that the device is STILL in the degraded/configuring state: $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 2 links listed. 8. Now, leave systemd-network-wait-online --any running while we attach another interface: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0 9. On the host, attach another interface to the VM on the default network, so that DHCP assigns the interface an IP: $ virsh attach-interface $VM network default 10. Back in the VM, the systemd-networkd-wait-online process should have exited with success, and networkctl should show the new link as configured, while the old one is still configuring: $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0 $ echo $? 0 $ networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 8 ens3 etherdegradedconfiguring 9 ens9 etherroutableconfigured 3 links listed. [Where problems could occur] This patch we want to remove is totally confined to systemd-networkd- wait-online, so that's where we would see problems. From what I can tell, the patch is no longer doing what it was intended to do. E.g. running systemd-networkd-wait-online on a desktop install, where systemd-networkd does not manage links, results in a timeout. It only works with the --any flag, but the --any flag did not exist when the patch was written. If a user was relying on --any to make systemd- networkd-wait-online exit when no links are managed, they will see a change in behavior as a result of this change. However,
[Touch-packages] [Bug 2033560] Re: package ufw 0.36.1-4ubuntu0.1 failed to install/upgrade: o subprocesso instalado, do pacote ufw, o script post-installation retornou erro do status de saída 10
The DpkgHistoryLog.txt has lots of entries that aren't ufw specific: Start-Date: 2023-08-16 18:22:34 Commandline: aptdaemon role='role-commit-packages' sender=':1.134' Upgrade: libgpgmepp6:amd64 (1.16.0-1.2ubuntu4, 1.16.0-1.2ubuntu4.1), libgl1-amber-dri:amd64 (21.3.7-0ubuntu1, 21.3.9-0ubuntu1~22.04.1), libglx-mesa0:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libglx-mesa0:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), python3-distupgrade:amd64 (1:22.04.16, 1:22.04.17), language-pack-en-base:amd64 (1:22.04+20230209, 1:22.04+20230801), libgtk-4-common:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), libunwind8:amd64 (1.3.2-2build2, 1.3.2-2build2.1), libldap-common:amd64 (2.5.15+dfsg-0ubuntu0.22.04.1, 2.5.16+dfsg-0ubuntu0.22.04.1), ufw:amd64 (0.36.1-4build1, 0.36.1-4ubuntu0.1), libgbm1:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgbm1:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), ubuntu-release-upgrader-gtk:amd64 (1:22.04.16, 1:22.04.17), libmutter-10-0:amd64 (42.9-0ubuntu1, 42.9-0ubuntu4), libwbclient0:amd64 (2:4.15.13+dfsg-0ubuntu1.2, 2:4.15.13+dfsg-0ubuntu1.3), language-pack-en:amd64 (1:22.04+20230209, 1:22.04+ 20230801), language-pack-pt:amd64 (1:22.04+20230209, 1:22.04+20230801), language-pack-gnome-en-base:amd64 (1:22.04+20230209, 1:22.04+20230801), libsmbclient:amd64 (2:4.15.13+dfsg-0ubuntu1.2, 2:4.15.13+dfsg-0ubuntu1.3), libxatracker2:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), gir1.2-gtk-4.0:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), mutter-common:amd64 (42.9-0ubuntu1, 42.9-0ubuntu4), python-apt-common:amd64 (2.4.0ubuntu1, 2.4.0ubuntu2), libgpgme11:amd64 (1.16.0-1.2ubuntu4, 1.16.0-1.2ubuntu4.1), language-pack-pt-base:amd64 (1:22.04+20230209, 1:22.04+20230801), libldap-2.5-0:amd64 (2.5.15+dfsg-0ubuntu0.22.04.1, 2.5.16+dfsg-0ubuntu0.22.04.1), mesa-va-drivers:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgl1-mesa-dri:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgl1-mesa-dri:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), terraform:amd64 (1.5.4-1, 1.5.5-1), gir1.2-mutter-10:amd64 (42.9-0ubuntu1, 42.9-0ubuntu4), mesa-vulkan-drivers:amd64 (22.2 .5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), mesa-vulkan-drivers:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), base-files:amd64 (12ubuntu4.3, 12ubuntu4.4), python3-apt:amd64 (2.4.0ubuntu1, 2.4.0ubuntu2), python3-distro-info:amd64 (1.1build1, 1.1ubuntu0.1), linux-firmware:amd64 (20220329.git681281e4-0ubuntu3.14, 20220329.git681281e4-0ubuntu3.17), language-pack-gnome-pt-base:amd64 (1:22.04+20230209, 1:22.04+20230801), distro-info:amd64 (1.1build1, 1.1ubuntu0.1), libglapi-mesa:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libglapi-mesa:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgtk-4-1:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), samba-libs:amd64 (2:4.15.13+dfsg-0ubuntu1.2, 2:4.15.13+dfsg-0ubuntu1.3), language-pack-gnome-en:amd64 (1:22.04+20230209, 1:22.04+20230801), language-pack-gnome-pt:amd64 (1:22.04+20230209, 1:22.04+20230801), thermald:amd64 (2.4.9-1ubuntu0.2, 2.4.9-1ubuntu0.3), libegl-mesa0:amd64 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04. 1), libegl-mesa0:i386 (22.2.5-0ubuntu0.1~22.04.3, 23.0.4-0ubuntu1~22.04.1), libgtk-4-bin:amd64 (4.6.6+ds-0ubuntu1, 4.6.9+ds-0ubuntu0.22.04.1), ubuntu-release-upgrader-core:amd64 (1:22.04.16, 1:22.04.17) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-16 18:25:33 Start-Date: 2023-08-18 17:51:20 Commandline: /usr/bin/unattended-upgrade Upgrade: ghostscript-x:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4), libgs9-common:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4), ghostscript:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4), libgs9:amd64 (9.55.0~dfsg1-0ubuntu5.3, 9.55.0~dfsg1-0ubuntu5.4) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-18 17:51:22 Start-Date: 2023-08-21 18:14:13 Commandline: apt-get install -y gnupg software-properties-common Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:14:14 Start-Date: 2023-08-21 18:23:11 Commandline: apt install terraform Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:23:12 Start-Date: 2023-08-21 18:24:55 Commandline: apt-get -f install Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:24:55 Start-Date: 2023-08-21 18:30:10 Commandline: apt -f install Requested-By: anderson (1000) Error: Sub-process /usr/bin/dpkg returned an error code (1) End-Date: 2023-08-21 18:30:10 Start-Date: 2023-08-21 18:38:25 Commandline: aptdaemon role='role-commit-packages' sender=':1.233' Upgrade: initramfs-tools-core:amd64 (0.140ubuntu13.2, 0.140ubuntu13.4),
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Note that autopkg tests for ufw test various aspects of normal ufw
usage, including ufw enable. I also performed the testing for this issue
on focal:
$ apt-cache policy ufw
ufw:
Installed: 0.36-6ubuntu1
Candidate: 0.36-6ubuntu1
Version table:
*** 0.36-6ubuntu1 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
100 /var/lib/dpkg/status
0.36-6 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
# recreate the WSL2 scenario by having the parent shell contain 'Relay(NNN)'.
# This could be done various ways, but the easiest is to create a script named
# /tmp/Relay(230) to launch ufw:
$ cat < "/tmp/Relay(230)"
#!/bin/bash
sudo ufw enable
EOM
$ chmod 755 "/tmp/Relay(230)"
# before the update
$ "/tmp/Relay(230)"
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ufw/util.py", line 444, in under_ssh
ppid = get_ppid(pid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in get_ppid
ppid = open(name).readlines()[0].split(')')[1].split()[1]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/ufw", line 138, in
not ui.continue_under_ssh():
File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 900, in
continue_under_ssh
if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover
File "/usr/lib/python3/dist-packages/ufw/util.py", line 474, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 474, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 451, in under_ssh
raise ValueError(err_msg)
ValueError: Couldn't find parent pid for '1782'
# after the update
$ cat
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
Note that autopkg tests for ufw test various aspects of normal ufw
usage, including ufw enable. I also performed the testing for this issue
on jammy:
$ apt-cache policy ufw
ufw:
Installed: 0.36.1-4build1
Candidate: 0.36.1-4build1
Version table:
*** 0.36.1-4build1 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
100 /var/lib/dpkg/status
# recreate the WSL2 scenario by having the parent shell contain 'Relay(NNN)'.
# This could be done various ways, but the easiest is to create a script named
# /tmp/Relay(230) to launch ufw:
$ cat < "/tmp/Relay(230)"
#!/bin/bash
sudo ufw enable
EOM
$ chmod 755 "/tmp/Relay(230)"
# before the update
$ "/tmp/Relay(230)"
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh
ppid = get_ppid(pid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid
ppid = open(name).readlines()[0].split(')')[1].split()[1]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/ufw", line 138, in
not ui.continue_under_ssh():
File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in
continue_under_ssh
if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh
raise ValueError(err_msg)
ValueError: Couldn't find parent pid for '1294'
# after the update
$ cat
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
For lunar, the crmsh autopkgtest issue was unrelated. I reran the autopkgtest
and it passed:
https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/c/crmsh/20230725_140910_37cd9@/log.gz
Note that autopkg tests for ufw test various aspects of normal ufw
usage, including ufw enable. I also performed the testing for this issue
on lunar:
$ apt-cache policy ufw
ufw:
Installed: 0.36.1-4.1
Candidate: 0.36.1-4.1
Version table:
*** 0.36.1-4.1 500
500 http://archive.ubuntu.com/ubuntu lunar/main amd64 Packages
100 /var/lib/dpkg/status
# recreate the WSL2 scenario by having the parent shell contain 'Relay(NNN)'.
# This could be done various ways, but the easiest is to create a script named
# /tmp/Relay(230) to launch ufw:
$ cat < "/tmp/Relay(230)"
#!/bin/bash
sudo ufw enable
EOM
$ chmod 755 "/tmp/Relay(230)"
# before the update
$ "/tmp/Relay(230)"
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh
ppid = get_ppid(pid)
^
File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid
ppid = open(name).readlines()[0].split(')')[1].split()[1]
~~~^^^
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/ufw", line 138, in
not ui.continue_under_ssh():
^^^
File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in
continue_under_ssh
if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
^^^
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
^^^
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
^^^
File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh
raise ValueError(err_msg)
ValueError: Couldn't find parent pid for '4496'
# after the update
$ cat
[Touch-packages] [Bug 2015645] Re: ufw crashes in wsl2
> I'll prepare an upload for Lunar, add a task and put these back to In
Progress after.
Uploaded 0.36.1-4.1ubuntu0.1 to Lunar.
** Also affects: ufw (Ubuntu Lunar)
Importance: Undecided
Status: New
** Changed in: ufw (Ubuntu Lunar)
Importance: Undecided => High
** Changed in: ufw (Ubuntu Lunar)
Status: New => In Progress
** Changed in: ufw (Ubuntu Lunar)
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
--
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/2015645
Title:
ufw crashes in wsl2
Status in ufw:
Fix Released
Status in ufw package in Ubuntu:
Fix Released
Status in ufw source package in Focal:
In Progress
Status in ufw source package in Jammy:
In Progress
Status in ufw source package in Lunar:
In Progress
Status in ufw source package in Mantic:
Fix Released
Bug description:
[ Impact ]
Currently, ufw is unusable on WSL due to this bug because the
get_ppid() function traces back on /proc when the command name has
parentheses (like in WSL). get_ppid() is called with 'ufw enable' and
so ufw is not able to be enabled on WSL. The upstream patch adjusts
get_ppid() for this and adds unit tests for this function.
[ Test Plan ]
Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw
status' to show that it was enabled. Importantly, this is called as
part of autopkgtests already.
Furthermore, look in the build logs for:
test_util
...
test_get_ppid (tests.unit.test_util.UtilTestCase)
Test get_ppid() ... ok
test_get_ppid_no_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() no space ... ok
test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase)
Test get_ppid() with parens ... ok
test_get_ppid_with_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() with space ... ok
...
--
Ran 49 tests in 0.355s
OK
[ Where problems could occur ]
The risk of regression is considered low since comprehensive unit
tests are added for the patched function. Not only is this change in
upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu
Mantic as part of 0.36.2-1.
# Original Description
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-
ubuntu-from-wsl2. You may already be aware of this error, I'm not sure
if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified that you can fix this issue by replacing the first split in
line 427 with rsplit(')', 1) so it splits based on the last
parenthesis instead of the all parenthesis.
Before:
ppid = open(name).readlines()[0].split(')')[1].split()[1]
After:
ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1]
C:\Users\caleb>wsl --version
WSL version: 1.1.6.0
Kernel version: 5.15.90.1
WSLg version: 1.0.50
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2728
➜ ufw git:(master) ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.
➜ ufw git:(master) cat /proc/229/stat | cut -c -23
229 (Relay(230)) S 228
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2015645/+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 2015645] Re: ufw crashes in wsl2
Oh, I did mean kinetic, yes. Lunar should get an update too (though, as
mentioned, that isn't in the Microsoft store it seems).
I'll prepare an upload for Lunar, add a task and put these back to In
Progress after.
--
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/2015645
Title:
ufw crashes in wsl2
Status in ufw:
Fix Released
Status in ufw package in Ubuntu:
Fix Released
Status in ufw source package in Focal:
In Progress
Status in ufw source package in Jammy:
In Progress
Status in ufw source package in Mantic:
Fix Released
Bug description:
[ Impact ]
Currently, ufw is unusable on WSL due to this bug because the
get_ppid() function traces back on /proc when the command name has
parentheses (like in WSL). get_ppid() is called with 'ufw enable' and
so ufw is not able to be enabled on WSL. The upstream patch adjusts
get_ppid() for this and adds unit tests for this function.
[ Test Plan ]
Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw
status' to show that it was enabled. Importantly, this is called as
part of autopkgtests already.
Furthermore, look in the build logs for:
test_util
...
test_get_ppid (tests.unit.test_util.UtilTestCase)
Test get_ppid() ... ok
test_get_ppid_no_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() no space ... ok
test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase)
Test get_ppid() with parens ... ok
test_get_ppid_with_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() with space ... ok
...
--
Ran 49 tests in 0.355s
OK
[ Where problems could occur ]
The risk of regression is considered low since comprehensive unit
tests are added for the patched function. Not only is this change in
upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu
Mantic as part of 0.36.2-1.
# Original Description
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-
ubuntu-from-wsl2. You may already be aware of this error, I'm not sure
if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified that you can fix this issue by replacing the first split in
line 427 with rsplit(')', 1) so it splits based on the last
parenthesis instead of the all parenthesis.
Before:
ppid = open(name).readlines()[0].split(')')[1].split()[1]
After:
ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1]
C:\Users\caleb>wsl --version
WSL version: 1.1.6.0
Kernel version: 5.15.90.1
WSLg version: 1.0.50
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2728
➜ ufw git:(master) ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.
➜ ufw git:(master) cat /proc/229/stat | cut -c -23
229 (Relay(230)) S 228
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2015645/+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 2015645] Re: ufw crashes in wsl2
Robie,
https://apps.microsoft.com/store/detail/ubuntu/9PDXGNCFSCZV?hl=en-
us=us=1 seems to indicate that only 22.04.2 is supported. Users
have talked about upgrading via the command line to 22.10, but I figured
that Lunar was about to EOL and no point in updating it at this time.
** Changed in: ufw (Ubuntu Focal)
Status: Incomplete => In Progress
** Changed in: ufw (Ubuntu Jammy)
Status: Incomplete => In Progress
--
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/2015645
Title:
ufw crashes in wsl2
Status in ufw:
Fix Released
Status in ufw package in Ubuntu:
Fix Released
Status in ufw source package in Focal:
In Progress
Status in ufw source package in Jammy:
In Progress
Status in ufw source package in Mantic:
Fix Released
Bug description:
[ Impact ]
Currently, ufw is unusable on WSL due to this bug because the
get_ppid() function traces back on /proc when the command name has
parentheses (like in WSL). get_ppid() is called with 'ufw enable' and
so ufw is not able to be enabled on WSL. The upstream patch adjusts
get_ppid() for this and adds unit tests for this function.
[ Test Plan ]
Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw
status' to show that it was enabled. Importantly, this is called as
part of autopkgtests already.
Furthermore, look in the build logs for:
test_util
...
test_get_ppid (tests.unit.test_util.UtilTestCase)
Test get_ppid() ... ok
test_get_ppid_no_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() no space ... ok
test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase)
Test get_ppid() with parens ... ok
test_get_ppid_with_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() with space ... ok
...
--
Ran 49 tests in 0.355s
OK
[ Where problems could occur ]
The risk of regression is considered low since comprehensive unit
tests are added for the patched function. Not only is this change in
upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu
Mantic as part of 0.36.2-1.
# Original Description
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-
ubuntu-from-wsl2. You may already be aware of this error, I'm not sure
if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified that you can fix this issue by replacing the first split in
line 427 with rsplit(')', 1) so it splits based on the last
parenthesis instead of the all parenthesis.
Before:
ppid = open(name).readlines()[0].split(')')[1].split()[1]
After:
ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1]
C:\Users\caleb>wsl --version
WSL version: 1.1.6.0
Kernel version: 5.15.90.1
WSLg version: 1.0.50
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2728
➜ ufw git:(master) ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.
➜ ufw git:(master) cat /proc/229/stat | cut -c -23
229 (Relay(230)) S 228
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2015645/+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 2015645] Re: ufw crashes in wsl2
Fyi, uploaded to 0.36.1-4ubuntu0.1 and 0.36-6ubuntu1.1 to jammy-proposed
and focal-proposed, respectively.
** Changed in: ufw (Ubuntu Focal)
Status: Triaged => In Progress
** Changed in: ufw (Ubuntu Jammy)
Status: Triaged => In Progress
** Changed in: ufw (Ubuntu Focal)
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
** Changed in: ufw (Ubuntu Jammy)
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
** Changed in: ufw (Ubuntu Mantic)
Assignee: (unassigned) => Jamie Strandboge (jdstrand)
--
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/2015645
Title:
ufw crashes in wsl2
Status in ufw:
Fix Released
Status in ufw package in Ubuntu:
Fix Released
Status in ufw source package in Focal:
In Progress
Status in ufw source package in Jammy:
In Progress
Status in ufw source package in Mantic:
Fix Released
Bug description:
[ Impact ]
Currently, ufw is unusable on WSL due to this bug because the
get_ppid() function traces back on /proc when the command name has
parentheses (like in WSL). get_ppid() is called with 'ufw enable' and
so ufw is not able to be enabled on WSL. The upstream patch adjusts
get_ppid() for this and adds unit tests for this function.
[ Test Plan ]
Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw
status' to show that it was enabled. Importantly, this is called as
part of autopkgtests already.
Furthermore, look in the build logs for:
test_util
...
test_get_ppid (tests.unit.test_util.UtilTestCase)
Test get_ppid() ... ok
test_get_ppid_no_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() no space ... ok
test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase)
Test get_ppid() with parens ... ok
test_get_ppid_with_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() with space ... ok
...
--
Ran 49 tests in 0.355s
OK
[ Where problems could occur ]
The risk of regression is considered low since comprehensive unit
tests are added for the patched function. Not only is this change in
upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu
Mantic as part of 0.36.2-1.
# Original Description
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-
ubuntu-from-wsl2. You may already be aware of this error, I'm not sure
if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified that you can fix this issue by replacing the first split in
line 427 with rsplit(')', 1) so it splits based on the last
parenthesis instead of the all parenthesis.
Before:
ppid = open(name).readlines()[0].split(')')[1].split()[1]
After:
ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1]
C:\Users\caleb>wsl --version
WSL version: 1.1.6.0
Kernel version: 5.15.90.1
WSLg version: 1.0.50
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2728
➜ ufw git:(master) ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.
➜ ufw git:(master) cat /proc/229/stat | cut -c -23
229 (Relay(230)) S 228
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2015645/+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 2015645] Re: ufw crashes in wsl2
** Description changed:
+ [ Impact ]
+
+ Currently, ufw is unusable on WSL due to this bug because the get_ppid()
+ function traces back on /proc when the command name has parentheses
+ (like in WSL). get_ppid() is called with 'ufw enable' and so ufw is not
+ able to be enabled on WSL. The upstream patch adjusts get_ppid() for
+ this and adds unit tests for this function.
+
+ [ Test Plan ]
+
+ Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw
+ status' to show that it was enabled. Importantly, this is called as part
+ of autopkgtests already.
+
+ Furthermore, look in the build logs for:
+
+ test_util
+ ...
+ test_get_ppid (tests.unit.test_util.UtilTestCase)
+ Test get_ppid() ... ok
+ test_get_ppid_no_space (tests.unit.test_util.UtilTestCase)
+ Test get_ppid() no space ... ok
+ test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase)
+ Test get_ppid() with parens ... ok
+ test_get_ppid_with_space (tests.unit.test_util.UtilTestCase)
+ Test get_ppid() with space ... ok
+ ...
+ --
+ Ran 49 tests in 0.355s
+
+ OK
+
+ [ Where problems could occur ]
+
+ The risk of regression is considered low since comprehensive unit tests
+ are added for the patched function. Not only is this change in upstream
+ ufw 0.36.2, it is already in Debian Bookworm and Ubuntu Mantic as part
+ of 0.36.2-1.
+
+
+ # Original Description
+
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-ubuntu-
from-wsl2. You may already be aware of this error, I'm not sure if
"NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified that you can fix this issue by replacing the first split in
line 427 with rsplit(')', 1) so it splits based on the last parenthesis
instead of the all parenthesis.
Before:
ppid = open(name).readlines()[0].split(')')[1].split()[1]
After:
ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1]
-
C:\Users\caleb>wsl --version
WSL version: 1.1.6.0
Kernel version: 5.15.90.1
WSLg version: 1.0.50
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2728
➜ ufw git:(master) ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.
➜ ufw git:(master) cat /proc/229/stat | cut -c -23
229 (Relay(230)) S 228
--
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/2015645
Title:
ufw crashes in wsl2
Status in ufw:
Fix Released
Status in ufw package in Ubuntu:
Fix Released
Status in ufw source package in Focal:
Triaged
Status in ufw source package in Jammy:
Triaged
Status in ufw source package in Mantic:
Fix Released
Bug description:
[ Impact ]
Currently, ufw is unusable on WSL due to this bug because the
get_ppid() function traces back on /proc when the command name has
parentheses (like in WSL). get_ppid() is called with 'ufw enable' and
so ufw is not able to be enabled on WSL. The upstream patch adjusts
get_ppid() for this and adds unit tests for this function.
[ Test Plan ]
Call 'sudo ufw enable' (it should not trace back) and call 'sudo ufw
status' to show that it was enabled. Importantly, this is called as
part of autopkgtests already.
Furthermore, look in the build logs for:
test_util
...
test_get_ppid (tests.unit.test_util.UtilTestCase)
Test get_ppid() ... ok
test_get_ppid_no_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() no space ... ok
test_get_ppid_with_parens (tests.unit.test_util.UtilTestCase)
Test get_ppid() with parens ... ok
test_get_ppid_with_space (tests.unit.test_util.UtilTestCase)
Test get_ppid() with space ... ok
...
--
Ran 49 tests in 0.355s
OK
[ Where problems could occur ]
The risk of regression is considered low since comprehensive unit
tests are added for the patched function. Not only is this change in
upstream ufw 0.36.2, it is already in Debian Bookworm and Ubuntu
Mantic as part of 0.36.2-1.
# Original Description
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-
ubuntu-from-wsl2. You may already be aware of this error, I'm not sure
if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified
[Touch-packages] [Bug 2003339] Re: kwin_x11: The X11 connection broke: I/O error (code 1)
According to the launchpad page for mesa 22.2.5-0ubuntu0.1~22.04.2 (https://launchpad.net/ubuntu/+source/mesa/22.2.5-0ubuntu0.1~22.04.2) the package is still in proposed, not updates. @tjaalton 's message in #72 suggests it has been released to updates but this appears incorrect. I'm on 22.04 with the updates archive enabled but not proposed and I'm not seeing the available update. Temporarily enabling proposed and looking at upgradable packages shows 22.2.5-0ubuntu0.1~22.04.2 which matches up which the launchpad page. Is there an ETA for this package to land in updates? -- 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/2003339 Title: kwin_x11: The X11 connection broke: I/O error (code 1) Status in KDE Base Workspace: Fix Released Status in Mesa: Fix Released Status in kwin package in Ubuntu: Invalid Status in mesa package in Ubuntu: Fix Released Status in kwin source package in Jammy: Invalid Status in mesa source package in Jammy: Fix Released Status in kwin package in Debian: New Bug description: [Impact] kwin might crash after running some time Two commits have been reverted upstream since 22.2.x branch was closed, needs those backported to fix this. [Test case] Run kwin for a day or so, which is usually enough time to hit this. Crash happens mostly on a notification popups, so system must be actively receiving notifications to test the crash. Without that crash may not happen even in a week of runtime. [Where things could go wrong] This just reverts two commits, and they have been upstream for a few months now, so these causing a regression is unlikely. To manage notifications about this bug go to: https://bugs.launchpad.net/kdebase-workspace/+bug/2003339/+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 1844743] Re: ufw missing .conf for syslog-ng
** Changed in: ufw Importance: Medium => Wishlist ** Changed in: ufw (Ubuntu) Importance: Medium => Wishlist -- 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/1844743 Title: ufw missing .conf for syslog-ng Status in ufw: Triaged Status in ufw package in Ubuntu: Triaged Bug description: ufw package contains /etc/rsyslog.d/20-ufw.conf, but no /etc/syslog-ng/conf.d/ufw.conf distro: any ufw: any To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1844743/+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 2015645] Re: ufw crashes in wsl2
** Also affects: ufw (Ubuntu)
Importance: Undecided
Status: New
** Also affects: ufw (Ubuntu Mantic)
Importance: Undecided
Status: New
** Also affects: ufw (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: ufw (Ubuntu Jammy)
Importance: Undecided
Status: New
** Changed in: ufw (Ubuntu Mantic)
Status: New => Triaged
** Changed in: ufw (Ubuntu Jammy)
Status: New => Triaged
** Changed in: ufw (Ubuntu Focal)
Status: New => Triaged
** Changed in: ufw (Ubuntu Mantic)
Importance: Undecided => High
** Changed in: ufw (Ubuntu Jammy)
Importance: Undecided => High
** Changed in: ufw (Ubuntu Focal)
Importance: Undecided => High
--
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/2015645
Title:
ufw crashes in wsl2
Status in ufw:
Fix Released
Status in ufw package in Ubuntu:
Triaged
Status in ufw source package in Focal:
Triaged
Status in ufw source package in Jammy:
Triaged
Status in ufw source package in Mantic:
Triaged
Bug description:
When I enable systemd in WSL2 (it became supported recently), install
ufw, and run sudo ufw enable, I get the error detailed in
https://superuser.com/questions/1775776/enabling-ufw-failed-with-
ubuntu-from-wsl2. You may already be aware of this error, I'm not sure
if "NotTheDr01ds" has talked to you about this yet. Note that the WSL2
/proc/[pid]/stat format, although weird, does comply with the spec:
https://man7.org/linux/man-pages/man5/proc.5.html
I verified that you can fix this issue by replacing the first split in
line 427 with rsplit(')', 1) so it splits based on the last
parenthesis instead of the all parenthesis.
Before:
ppid = open(name).readlines()[0].split(')')[1].split()[1]
After:
ppid = open(name).readlines()[0].rsplit(')',1)[1].split()[1]
C:\Users\caleb>wsl --version
WSL version: 1.1.6.0
Kernel version: 5.15.90.1
WSLg version: 1.0.50
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2728
➜ ufw git:(master) ufw --version
ufw 0.36
Copyright 2008-2015 Canonical Ltd.
➜ ufw git:(master) cat /proc/229/stat | cut -c -23
229 (Relay(230)) S 228
To manage notifications about this bug go to:
https://bugs.launchpad.net/ufw/+bug/2015645/+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 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
This was fixed in 0.36.2. ** Changed in: ufw Status: Fix Committed => 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/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: Fix Released Status in ufw package in Ubuntu: Triaged Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+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 1946804] Re: ufw breaks boot on network root filesystem
This was fixed in 0.36.2. ** Changed in: ufw Importance: Undecided => Medium ** Changed in: ufw Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw Status: Fix Committed => Fix Released ** Changed in: ufw (Ubuntu) Importance: Undecided => Medium -- 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/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Released Status in ufw source package in Focal: Fix Released Status in ufw source package in Hirsute: Fix Released Status in ufw source package in Impish: Fix Released Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] conn
[Touch-packages] [Bug 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
Thank you for reporting a bug in ufw. I've committed a fix for this to add get_rules_ipv4() and get_rules_ipv6(). ** Changed in: ufw Importance: Undecided => Wishlist ** Changed in: ufw Status: New => Fix Committed ** Changed in: ufw Assignee: (unassigned) => Jamie Strandboge (jdstrand) ** Changed in: ufw (Ubuntu) Status: New => Triaged ** Changed in: ufw (Ubuntu) Importance: Undecided => Wishlist -- 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/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: Fix Committed Status in ufw package in Ubuntu: Triaged Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+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 2014031] Re: ufw fails trying to enable
*** This bug is a duplicate of bug 2015645 ***
https://bugs.launchpad.net/bugs/2015645
This looks like it may be a dupe of
https://bugs.launchpad.net/bugs/2015645 (the fix for it should fix
this).
** Changed in: ufw (Ubuntu)
Status: New => Confirmed
** This bug has been marked a duplicate of bug 2015645
ufw crashes in wsl2
--
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/2014031
Title:
ufw fails trying to enable
Status in ufw package in Ubuntu:
Confirmed
Bug description:
root@SW556127-UY:~# sudo ufw enable
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh
ppid = get_ppid(pid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid
ppid = open(name).readlines()[0].split(')')[1].split()[1]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/ufw", line 138, in
not ui.continue_under_ssh():
File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in
continue_under_ssh
if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
[Previous line repeated 1 more time]
File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh
raise ValueError(err_msg)
ValueError: Couldn't find parent pid for '257'
root@SW556127-UY:~# lsb_release -rd
Description:Ubuntu 22.04.2 LTS
Release:22.04
root@SW556127-UY:~# apt-cache policy ufw
ufw:
Installed: 0.36.1-4build1
Candidate: 0.36.1-4build1
Version table:
*** 0.36.1-4build1 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/2014031/+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 2014031] Re: ufw fails trying to enable
Thanks for the report. Does this happen every time of just occasionally?
It's clear that the open(name).readlines() isn't returning anything,
which is interesting. Do you have any other information on what might be
causing this? (the fix should be straightforward without it though)
--
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/2014031
Title:
ufw fails trying to enable
Status in ufw package in Ubuntu:
New
Bug description:
root@SW556127-UY:~# sudo ufw enable
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/ufw/util.py", line 427, in under_ssh
ppid = get_ppid(pid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 419, in get_ppid
ppid = open(name).readlines()[0].split(')')[1].split()[1]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/sbin/ufw", line 138, in
not ui.continue_under_ssh():
File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 901, in
continue_under_ssh
if self.backend.do_checks and ufw.util.under_ssh(): # pragma: no cover
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
File "/usr/lib/python3/dist-packages/ufw/util.py", line 457, in under_ssh
return under_ssh(ppid)
[Previous line repeated 1 more time]
File "/usr/lib/python3/dist-packages/ufw/util.py", line 434, in under_ssh
raise ValueError(err_msg)
ValueError: Couldn't find parent pid for '257'
root@SW556127-UY:~# lsb_release -rd
Description:Ubuntu 22.04.2 LTS
Release:22.04
root@SW556127-UY:~# apt-cache policy ufw
ufw:
Installed: 0.36.1-4build1
Candidate: 0.36.1-4build1
Version table:
*** 0.36.1-4build1 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
100 /var/lib/dpkg/status
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/2014031/+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 1951491] Re: Can't run snaps: .slice/session-1.scope is not a snap cgroup
For those of us who are using Xubuntu, X2Go and experiencing this problem, I have a work-around: I had already switched firefox to the apt repository version, so I installed the chromium snap to test with. As expected, it failed to launch with the same issue mentioned at the top of this thread: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup So, I added this file: /etc/x2go/Xsession.d/96dbus-snap-fix containing: export DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" After logging out and back in via X2Go, the Chromium snap worked. It is my hope that this fixes snaps for ALL users without having to edit individual user login files (like .bashrc). -- 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/1951491 Title: Can't run snaps: .slice/session-1.scope is not a snap cgroup Status in X2Go: New Status in Xpra Terminal Server: New Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Incomplete Status in x2goserver package in Ubuntu: Confirmed Status in snapd package in Debian: New Status in snapd package in Fedora: New Bug description: I just upgraded from hirsute to impish using do-release-upgrade. On the upgraded system, I can't run either firefox or chromium (both of which worked fine under hirsute). Both fail with: /user.slice/user-NNN.slice/session-1.scope is not a snap cgroup where NNN is my uid With firefox, I was able to fix the problem with: snap remove --purge firefox apt purge firefox apt install firefox Now firefox works. But I tried the same thing substituting chromium- browser for firefox, and it didn't help: chromium fails with the same error message. I guess there must be something left over from the hirsute version of snapd that isn't getting noticed or cleared by the impish version? Someone suggested this might be related to bug 1850667, but that bug is marked fixed as of a couple months ago, and I just did this upgrade today. Also, it doesn't mention the error message I'm seeing. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: snapd 2.53+21.10ubuntu1 ProcVersionSignature: Ubuntu 5.13.0-21.21-generic 5.13.18 Uname: Linux 5.13.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: unknown Date: Thu Nov 18 18:12:45 2021 InstallationDate: Installed on 2020-04-29 (568 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: snapd UpgradeStatus: Upgraded to impish on 2021-11-18 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/x2go/+bug/1951491/+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 1971409] Re: value_copy: Assertion `arg->contents != nullptr' failed.
see also https://sourceware.org/bugzilla/show_bug.cgi?id=29045#c3 where the gdb list recommends updating to a stable version of gdb ** Bug watch added: Sourceware.org Bugzilla #29045 https://sourceware.org/bugzilla/show_bug.cgi?id=29045 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1971409 Title: value_copy: Assertion `arg->contents != nullptr' failed. Status in gdb package in Ubuntu: Confirmed Bug description: When debugging RP2040 with vscode this assert makes gdb crash. This is a new assert, that wasn't present in gdb 11. The fix is easy, replace `if (!value_lazy (val))` to `if (!value_lazy (val) && arg->contents != nullptr) `. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1971409/+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 1970731] Re: iptables empty when using firewalld
Reassigning to firewalld as the description mentions that ufw is disabled. This is not a bug though because iptables relies on certain tables/chains being used and it looks like firewalld doesn't use those (which is fine for firewalld to do). You should be able to see all netfilter firewall rules with 'nft' but you'll only see rules that are added to the (now non-default) tables/chains that iptables expects (INPUT, OUTPUT, etc). More specifically, 'nft' will see the rules that 'iptables' creates but not necessarily the other way around. ** Package changed: ufw (Ubuntu) => firewalld (Ubuntu) ** Changed in: firewalld (Ubuntu) Status: New => Invalid -- 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/1970731 Title: iptables empty when using firewalld Status in firewalld package in Ubuntu: Invalid Bug description: Summary: I am using firewalld/jammy,now 1.1.1-1ubuntu1 on my vpn server. The vpn server is using wireguard and I could successfully configure zones and policies in firewalld. Yet, iptables does not show the rules from firewalld. 1) System root@vpn:~# uname -a Linux vpn 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 04:55:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@vpn:~# lsb_release -rd Description: Ubuntu 22.04 LTS Release: 22.04 All updates installed. 2) What happens: I am setting rules with firewall-cmd. These firewall rules are visible with: nft list table inet firewalld but not with 'iptables'. 3) What I expect to happen: The toutput of iptables --list should also reflect firewalld settings. 4) What happened instead However, the iptables output shows only empty tables (filter, mangle, nat). root@vpn:~# iptables -t nat --list # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination root@vpn:~# iptables -t filter --list # Warning: iptables-legacy tables present, use iptables-legacy to see them Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination root@vpn:~# iptables-legacy -t nat --list Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination root@vpn:~# iptables-legacy -t filter --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 5) Further information The ufw firewall is disabled and uninstalled. According to the release notes of 22.04, the backend has changed to nftables. I was assuming, that the backend default is kind of transparent to the user, meaning iptables should still work as normal. I wonder if on my system is iptables correctly linked to the backend. Iptables points to xtables-nft-multi: root@vpn:~# ls -l /usr/sbin/iptables lrwxrwxrwx 1 root root 26 Aug 24 2021 /usr/sbin/iptables -> /etc/alternatives/iptables root@vpn:~# ls -l /etc/alternatives/iptables lrwxrwxrwx 1 root root 22 Apr 25 18:56 /etc/alternatives/iptables -> /usr/sbin/iptables-nft root@vpn:~# ls -l /usr/sbin/iptables-nft lrwxrwxrwx 1 root root 17 Mar 24 12:58 /usr/sbin/iptables-nft -> xtables-nft-multi root@vpn:~# ls -l /usr/sbin/xtables-nft-multi -rwxr-xr-x 1 root root 224296 Mar 24 12:58 /usr/sbin/xtables-nft-multi Perhaps this is an issue with the upgrade process of ubuntu. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firewalld/+bug/1970731/+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 1896772] Re: systemd-resolved configures no Current Scopes on start
** Changed in: isc-dhcp (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in ifupdown package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Triaged Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+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 1896772] Re: systemd-resolved configures no Current Scopes on start
** Changed in: ifupdown (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in ifupdown package in Ubuntu: In Progress Status in isc-dhcp package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+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 1896772] Re: systemd-resolved configures no Current Scopes on start
** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1896772 Title: systemd-resolved configures no Current Scopes on start Status in ifupdown package in Ubuntu: New Status in isc-dhcp package in Ubuntu: New Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1896772/+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 1896772] Re: systemd-resolved configures no Current Scopes on start
I grep'd for 'netif' in /etc and noticed: $ sudo grep -r netif /etc /etc/network/if-down.d/resolved:statedir=/run/systemd/resolve/netif /etc/network/if-up.d/resolved:statedir=/run/systemd/resolve/netif /etc/dhcp/dhclient-exit-hooks.d/resolved:statedir=/run/systemd/resolve/netif /etc/network/if-up.d/resolved and /etc/dhcp/dhclient-exit- hooks.d/resolved have code like this: statedir=/run/systemd/resolve/netif mkdir -p $statedir but do not have a corresponding chown of /run/systemd/resolve/netif. There is a chown for `chown systemd-resolve:systemd-resolve "$statedir/$ifindex"` in /etc/network/if-up.d/resolved and /etc/dhcp/dhclient-exit-hooks.d/resolved. This system has been upgraded many, many times (at least since yakkety). dhclient is being used for this interface. ifupdown is installed. -- 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/1896772 Title: systemd-resolved configures no Current Scopes on start Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net
[Touch-packages] [Bug 1896772] Re: systemd-resolved configures no Current Scopes on start
I see this on 22.04 after upgrading from 20.04. $ journalctl |grep 'Failed to save link data' Apr 17 15:25:52 hostname systemd-resolved[19095]: Failed to save link data /run/systemd/resolve/netif/3: Permission denied Apr 17 15:25:52 hostname systemd-resolved[19095]: Failed to save link data /run/systemd/resolve/netif/3: Permission denied $ ls -ld /run/systemd/resolve/netif drwxr-xr-x 2 root root 40 Apr 17 14:46 /run/systemd/resolve/netif (note, I had tried to restart systemd-resolved) -- 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/1896772 Title: systemd-resolved configures no Current Scopes on start Status in systemd package in Ubuntu: Confirmed Bug description: Running groovy on the desktop, with the systemd packages that migrated today(/overnight EDT). # Steps to reproduce: 1) `systemctl restart systemd-resolved.service` (This is a minimal reproducer, but I first saw this after an apt upgrade of systemd.) # Expected behaviour: DNS continues to work, status looks like this: Link 2 (enp5s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.1.1 DNS Servers: 192.168.1.1 DNS Domain: ~. lan # Actual behaviour: DNS is unconfigured: Link 2 (enp5s0) Current Scopes: none DefaultRoute setting: no LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no # Workaround Disconnecting and reconnecting my network connection restored DNS functionality. ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.5-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-18.19-generic 5.8.4 Uname: Linux 5.8.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu45 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: i3 CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Wed Sep 23 09:05:42 2020 InstallationDate: Installed on 2019-05-07 (504 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-18-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 RebootRequiredPkgs: gnome-shell SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (92 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896772/+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 1968608] Re: networking/firewall issues after upgrade when using iptables-nft
I filed https://github.com/docker-snap/docker-snap/issues/68 for the docker snap unconditionally using xtables. ** Bug watch added: github.com/docker-snap/docker-snap/issues #68 https://github.com/docker-snap/docker-snap/issues/68 ** Also affects: iptables (Ubuntu) Importance: Undecided Status: New ** Changed in: iptables (Ubuntu) Status: New => Invalid -- 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/1968608 Title: networking/firewall issues after upgrade when using iptables-nft Status in ufw: Invalid Status in iptables package in Ubuntu: Invalid Status in ufw package in Ubuntu: Invalid Bug description: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables- legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables- nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables- legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non-distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see
[Touch-packages] [Bug 1968608] Re: networking/firewall issues after upgrade when using iptables-nft
** Description changed: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables-legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables-nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables-legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non- distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that 'sudo nft list ruleset' has only accept rules if 'iptables- legacy -S' shows rules are in use. If there is a mixture of rules in both backends, you'll need to make everything use either netfilter or xtables. If things were working correctly before the upgrade, you might find that going back to iptables-legacy could make things work until you're ready to migrate to iptables-nft (on Debian/Ubuntu, see update-alternatives, above). The 'docker' snap as of 20.10.12 in the stable channel is known to unconditionally use xtables. At the time of this filing, it did not have a way to adjust to using netfilter, so if using the docker snap, you might have to update your system to use
[Touch-packages] [Bug 1968608] [NEW] networking/firewall issues after upgrade when using iptables-nft
Public bug reported: Filing this issue in the hopes that it will help people who are upgrading from a system that previously used xtables to one that is using netfilter. ufw uses the 'iptables' suite of commands under the hood. As of iptables 1.8, iptables ships with two different backends for these commands: * nft (netfilter) * legacy (xtables) such that there are iptables-nft, iptables-legacy, ip6tables-nft, ip6tables-legacy, etc commands on the system. Distributions may choose to then install symlinks from these commands to the traditional command. Eg, iptables will point to either iptables-nft or iptables-legacy. These symlinks can be configured by the admin on Debian/Ubuntu-based systems with: $ sudo update-alternatives --config iptables # configures all the iptables* symlinks $ sudo update-alternatives --config ip6tables # configures all the ip6tables* symlinks ufw is fully compatible with either backend. iptables-nft and nftables (ie, the 'nft' command not part of 'iptables'; will refer to this here as 'nftables' for clarity) both work with the kernel netfilter and different software on the system may freely use iptables-nft or nftables (eg, ufw using iptables-nft with other software (eg, libvirt) using nftables is fine). Since iptables-nft works well for ufw's requirements, there hasn't been a compelling reason to migrate ufw to use 'nftables' instead of 'iptables'. While iptables-nft and nftables can be used together, you should NOT mix and match netfilter and xtables rules as the upstream kernel considers this undefined and the firewall may not work correctly. Before iptables 1.8, admins could not mix and match iptables and nftables (or software that used one or the other). With iptables 1.8, admins can choose to use iptables-legacy or nftables and/or iptables-nft. Older releases of distributions (eg, Ubuntu 20.04 LTS) defaulted to iptables-legacy as the iptables backend with the admin able to opt into iptables-nft. Newer releases of distributions (eg, Ubuntu 22.04 LTS) are choosing to default to iptables-nft instead. As mentioned, so long as all of the software on the system agrees on using either netfilter or xtables, everything should be fine. Use of the symlink mechanism (eg, the aforementioned 'update-alternatives' on Debian/Ubuntu) helps ensure everything works properly. Software that manipulates the firewall outside of the configured symlinks (or using iptables-legacy/iptables 1.6 while nftables is also in use) might introduce problems if they are not aware of the xtables/netfilter incompatibility. Eg, this might happen with snaps that ship their own iptables or nftables and unconditionally use it without considering existing rules on the system. The ufw snap will detect and use the correct backend for the system on startup. The lxd and multipass snaps will do the same. As such, eg, an Ubuntu 20.04 system that is configured with the default iptables-legacy backend can use the ufw deb from Ubuntu with the lxd and multipass snaps without issue (ufw follows the iptables symlink to use the legacy (xtables) backend to load firewall rules in early boot. When lxd and multipass are started, they see that legacy rules are in use and use xtables). Similarly, on an Ubuntu 22.04 system that is configured with the default iptables-nft backend, the ufw deb from Ubuntu will follow the iptables symlink to use the nft (netfilter) backend to load firewall rules in early boot. When lxd and multipass are started, the see that nft rules are in use and use netfilter. Users upgrading from earlier distributions that defaulted to the legacy backend to newer releases that use the nft backend may find that non- distro software isn't choosing the correct backend. You can see if this is the case by running: $ sudo iptables-nft -S and compare with: $ sudo iptables-legacy -S If one is populated and the other comes back with only: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT then everything should be operating together ok. You should also check ip6tables-nft vs ip6tables-legacy and if you have 'nft' on your system, see that 'sudo nft list ruleset' has only accept rules if 'iptables- legacy -S' shows rules are in use. If there is a mixture of rules in both backends, you'll need to make everything use either netfilter or xtables. If things were working correctly before the upgrade, you might find that going back to iptables-legacy could make things work until you're ready to migrate to iptables-nft (on Debian/Ubuntu, see update-alternatives, above). The 'docker' snap as of 20.10.12 in the stable channel is known to unconditionally use xtables. At the time of this filing, it did not have a way to adjust to using netfilter, so if using the docker snap, you might have to update your system to use iptables-legacy (on Debian/Ubuntu, see update-alternatives, above). Finally, if using various container/VM software with ufw on the host and everything agrees on using the same backend, you might check
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Tags removed: block-proposed block-proposed-jammy -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
https://launchpad.net/ubuntu/+source/ufw/0.36.1-3ubuntu1 -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Changed in: ufw (Ubuntu) Status: New => Triaged ** Changed in: cloud-init (Ubuntu) Status: New => Invalid -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Oh! I missed from the initial report that network-pre was deleted which clears up things considerably on my end (since I wasn't able to reproduce, I didn't see it locally either). :) Preparing an upload now. -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: Invalid Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+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
Thanks for the response and glad you got it worked out. It reminds me that I would like to document using fail2ban with ufw more. ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- 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: Invalid 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 # # Set to yes to apply rules to support IPv6 (no
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
> This makes me want to understand the cloud-init configuration that is in play. Can you share it? I'm thinking I should upload: DefaultDependencies=no Before=network-pre.target Wants=network-pre.target local-fs.target After=local-fs.target Do you have any objections? This would remove the explicit sysinit from the dependency equation but I think it would otherwise achieve ufw's startup objectives. -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
> I don't believe your reproducer is valid - cloud-init is not installed anymore, as autopkgtest-buildvm-ubuntu-cloud removes it when building the VM, whereas it remains on the cloud images, as it's needed there to actually get the IP address during boot. Note, in https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/comments/9 I installed cloud-init and did some analysis also (but see below). > Though arguably I'd expect this to be fixed by removing DefaultDependencies again, if I looked at this correctly. Seems likely, though this change was done to fix an issue people were seeing on stack exchange for Debian/Ubuntu systems related to a race between encrypted filesystems and ufw. I guess I could add back DefaultDependencies=no and add After=local-fs.target, but I'm not sure what this would do in practice since local-fs.target is so close to the end of sysinit anyway (but see below). In 0.36.1-2, ufw has: DefaultDependencies=no Before=network.target In 0.36.1-3, ufw has (no DefaultDependencies=no): Before=network-pre.target Wants=network-pre.target cloud-init has (among other things): Before=sysinit.target Before=network-pre.target Wants=network-pre.target AIUI, with 0.36.1-2, ufw will tend to start right away due to DefaultDependencies=no and so will cloud-init so long as it finishes before sysinit. ufw need only finish before network.target, which is after network-pre.target. Eg, ufw and cloud-init race to complete but otherwise their dependencies directly don't affect each other. With 0.36.1-3, cloud-init starts early and before ufw since it must finish before sysinit.target and ufw cannot start until after sysinit.target is done. Because both must finish before network- pre.target, this pushes network-pre.target after sysinit (and of course, ufw), but other than that, there shouldn't be a problem since we have: 1. cloud-init starts / finishes 2. sysinit starts / finishes 3. ufw starts / finishes 4. network-pre reached 5. systemd-networkd starts / finishes 6. network reached IME, there is no obvious problem with the dependencies (as they relate to ufw) since cloud-init is allowed to start/finish before sysinit and network-pre just like before. It is just that now network-pre is guaranteed to be after sysinit (which from cloud-init's point of view, shouldn't necessarily be a concern). It is also guaranteed to be after ufw but, unless cloud-init is doing something with ufw such as perhaps enabling ufw and restarting the ufw service, cloud-init shouldn't care cause the ufw service doesn't do anything unless ufw is enabled (and even when it is enabled, it just loads firewall rules). This makes me want to understand the cloud-init configuration that is in play. Can you share it? -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in cloud-init package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on
[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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Attachment added: "plot-2.svg" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+attachment/5550320/+files/plot-2.svg -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Attachment added: "plot-3.svg" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+attachment/5550321/+files/plot-3.svg -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Attached are two 'systemd-analyze plot's for the autopktest jammy system with cloud-init and ufw installed. plot-2.svg is for booting the system with 0.36.1-2 (current jammy) and plot-3.svg is 0.36.1-3 (proposed jammy). Notice how plot-2.svg, ufw and systemd-networkd start quite a bit earlier than in plot-3.svg. -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
@juliank - note I wasn't so much talking about 'blame' as much as understanding, so I apologize if it came across that way. Since I wasn't able to reproduce, I was trying to reason through my thoughts to help the discussion go further since I'm not able to diagnose it myself. In a nutshell, I have concerns that the ufw service has a side effect that somewhere else in the system is dependent on. That other part of the system should be setup to work without ufw in the mix. I'm also concerned that users might face issues if ufw is purged or if other similarly configured software is installed (eg, firewalld). With that in mind, it seems odd that a service that does nearly nothing by default would affect the system by having a Before/Wants on network- pre.target. It also seems odd that going from very little dependencies (DefaultDependencies=no) to have only those for 'basic system initialization' would be a problem since those are not related to networking, etc. Eg, in today's autopkgtest jammy instance that I created with `autopkgtest-buildvm-ubuntu-cloud -r jammy` and rebooting with the proposed -3 of ufw installed: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu Jammy Jellyfish (development branch) Release:22.04 Codename: jammy $ cat /proc/version_signature Ubuntu 5.13.0-19.19-generic 5.13.14 $ systemctl list-dependencies ufw.service ufw.service ● ├─system.slice ● ├─network-pre.target ● └─sysinit.target ● ├─apparmor.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─keyboard-setup.service ● ├─kmod-static-nodes.service ● ├─multipathd.service ● ├─plymouth-read-write.service ○ ├─plymouth-start.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─setvtrgb.service ● ├─sys-fs-fuse-connections.mount ● ├─sys-kernel-config.mount ● ├─sys-kernel-debug.mount ● ├─sys-kernel-tracing.mount ● ├─systemd-ask-password-console.path ○ ├─systemd-binfmt.service ○ ├─systemd-boot-system-token.service ● ├─systemd-journal-flush.service ● ├─systemd-journald.service ○ ├─systemd-machine-id-commit.service ● ├─systemd-modules-load.service ○ ├─systemd-pstore.service ● ├─systemd-random-seed.service ● ├─systemd-sysctl.service ● ├─systemd-sysusers.service ● ├─systemd-timesyncd.service ● ├─systemd-tmpfiles-setup-dev.service ● ├─systemd-tmpfiles-setup.service ● ├─systemd-udev-trigger.service ● ├─systemd-udevd.service ● ├─systemd-update-utmp.service ● ├─cryptsetup.target ● ├─local-fs.target ● │ ├─-.mount ● │ ├─boot-efi.mount ○ │ ├─systemd-fsck-root.service ● │ └─systemd-remount-fs.service ● ├─swap.target ● └─veritysetup.target Seeing what depends on ufw, there is very little: $ systemctl list-dependencies ufw.service --reverse ufw.service ● └─multi-user.target ● └─graphical.target I can also say that nothing in this VM depends on network-pre other than ufw: $ systemctl list-dependencies --reverse network-pre.target network-pre.target ● └─ufw.service and that there is not much depending on network.target: $ systemctl list-dependencies --reverse network.target network.target ○ ├─netplan-ovs-cleanup.service ● └─systemd-networkd.service Rebooting with ufw -2 installed, all of the above is the same except ufw's dependencies are nearly nothing: $ systemctl list-dependencies ufw.service ufw.service ● └─system.slice This autopkgtest VM doesn't have cloud-init installed (which is consistent with why I'm not seeing it in here like I am not in Debian) and I don't know what cloud-init config to provide to provide any additional diagnosis. I can say that if I install cloud-init, it add a dependency on on network-pre.target (still with -2 of ufw): $ systemctl list-dependencies network-pre.target --reverse network-pre.target ○ └─cloud-init-local.service It has: $ cat /usr/lib/systemd/system/cloud-init-local.service [Unit] Description=Initial cloud-init job (pre-networking) DefaultDependencies=no Wants=network-pre.target After=hv_kvp_daemon.service After=systemd-remount-fs.service Before=NetworkManager.service Before=network-pre.target Before=shutdown.target Before=sysinit.target Conflicts=shutdown.target RequiresMountsFor=/var/lib/cloud [Service] Type=oneshot ExecStart=/usr/bin/cloud-init init --local ExecStart=/bin/touch /run/cloud-init/network-config-ready RemainAfterExit=yes TimeoutSec=0 # Output needs to appear in instance console output StandardOutput=journal+console [Install] WantedBy=cloud-init.target I notice that it has a `Before=sysinit.target` and DefaultDependencies=no. Is cloud-init in our infrastructure configured to run ufw? -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: New Bug description:
[Touch-packages] [Bug 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
** Changed in: ufw (Ubuntu) Status: Triaged => 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Incomplete Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
@juliank - where did you see these errors? I booted with a freshly created autopkgtest jammy vm, installed the package from proposed and it worked fine. Please see my previous comments-- this does not seem to be a bug in ufw since it is using the documented unit setup that systemd recommends for firewall software (and that other firewall software use, such as firewalld) and this has been in Debian for some time now with no bug reports (indeed, it solved issues). Your initial report shows that lots of other units have the ordering cycle issue that you mentioned so I'm not sure why ufw would be singled out. So we're all on the same page, this was the change: -DefaultDependencies=no -Before=network.target +Before=network-pre.target +Wants=network-pre.target and I'll add this from debian/changelog: +- use Before and Wants on network-pre.target. Per systemd documentation, + "network-pre.target is a target that may be used to order services + before any network interface is configured. Its primary purpose is for + usage with firewall services". Because network-pre.target is a passive + unit, "services that want to be run before the network is configured + should place Before=network-pre.target and also set + Wants=network-pre.target to pull it in" +- remove DefaultDependencies=no so that we pull in default dependencies + for "basic system initialization". While ufw is meant to come up before + networking, there is no reason why it shouldn't come up after sysinit. + This should help make ufw startup more robust on systems that need + something from sysinit. The ufw unit itself does very little unless ufw is enabled since /lib/ufw/ufw-init exits very quickly when it is not enabled. As such, it seems to me that the ufw upload may have uncovered a latent issue in our early boot (but that wouldn't be a bug in ufw itself) where Ubuntu may not be supporting the documented behavior for network-pre.target. Finally, it has been a couple of months since this report; is it possible to rerun wherever this was run to see if it is still an issue (as mentioned, no bug reports in Debian and so perhaps things floated in that resolved this)? I would rerun autopkgtests, but they all have passed. -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
@Stefan, I suggest you try the fix that is in Debian. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834#27 @Myron, yours sounds like a different issue. I suggest you file a new bug, downloading https://git.launchpad.net/ufw/tree/tests/check- requirements and including the output of 'sudo sh /path/to/check- requirements'. -- 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 1951018] Re: No ability to discern IPv4 vs IPv6 rules through Python
** Also affects: ufw Importance: Undecided Status: New -- 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/1951018 Title: No ability to discern IPv4 vs IPv6 rules through Python Status in ufw: New Status in ufw package in Ubuntu: New Bug description: Version: ufw 0.36 Ubuntu Version: 20.04.3 LTS There doesn't appear to be a Python method for accessing IPv4 and IPv6 rules in a distinguishable manner. In the source code (root/src/backend.py) there is an object that stores IPv4 and IPv6 rules in separate lists. Those lists are then accessed with the following method: def get_rules(self): '''Return list of all rules''' return self.rules + self.rules6 The issue with this is that the returned list doesn't contain an indication of what IP version each item corresponds to and would display something like the following. 1 allow 22/tcp 2 allow 80 3 allow 443 4 allow 22/tcp 5 allow 80 6 allow 443 I don't currently see a way to distinguish between IPv4 and IPv6 rules other than accessing the lists in the backend object directly (but I don't think this is best practice). E.g.: rules_ipv4 = backend.rules rules_ipv6 = backend.rules6 One possible fix would be to add functions that return only the IPv4 or IPv6 rules. E.g.: def get_rules_ipv4(self): '''Return list of all ipv4 rules''' return self.rules def get_rules_ipv6(self): '''Return list of all ipv6 rules''' return self.rules6 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1951018/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Also, to be clear, when I say I can't look at the ufw portions 'for a while', I mean ~10 days (doing this from my phone). Thinking about this, my thinking is this is less about the Before/Wants on network-pre and the removal of DefaultDependencies and more about Before=network being removed (with perhaps nothing else doing that? ie, I don't think this an ufw bug; I think the change uncovered something). -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
I mention firewalld cause while ufw could be reverted, firewalld users would presumably also hit it, as well as any other software that does it. If the ufw change is reverted, IME someone should audit the archive for other occurrences of this pattern and update the units accordingly). -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1950039] Re: ufw 0.36.1-3 introduces ordering cycle, breaking network
Fyi, the current configuration is the same as firewalld upstream and what is in Debian, Moreover it is following systemd documentation for firewall software so I wonder if the change simply uncovered a latent bug Fyi, I won't be able to look at this for a while so if you need to back it out, please do an ubuntu1 upload (though it would be great if someone more familiar with systemd-networkd thought through my latent bug comment). -- 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/1950039 Title: ufw 0.36.1-3 introduces ordering cycle, breaking network Status in ufw package in Ubuntu: Triaged Bug description: [2.065178] systemd[1]: systemd-networkd.service: Found ordering cycle on network-pre.target/start [2.065276] systemd[1]: systemd-networkd.service: Found dependency on ufw.service/start [2.065356] systemd[1]: systemd-networkd.service: Found dependency on basic.target/start [2.065422] systemd[1]: systemd-networkd.service: Found dependency on sockets.target/start [2.065487] systemd[1]: systemd-networkd.service: Found dependency on cloud-init-hotplugd.socket/star t [2.065561] systemd[1]: systemd-networkd.service: Found dependency on sysinit.target/start [2.065626] systemd[1]: systemd-networkd.service: Found dependency on cloud-init.service/start [2.065700] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd-wait-online.se rvice/start [2.065795] systemd[1]: systemd-networkd.service: Found dependency on systemd-networkd.service/start [2.065870] systemd[1]: systemd-networkd.service: Job network-pre.target/start deleted to break ordering cycle starting with systemd-networkd.service/start [[0;1;31m SKIP [0m] Ordering cycle found, skipping [0;1;39mNetwork (Pre)[0m To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1950039/+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 1946804] Re: ufw breaks boot on network root filesystem
Tested 0.36-0ubuntu0.18.04.2 on bionic. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I didn't test on an iSCSI system so won't add verification-done-focal at this time, but I think the testing is probably sufficient for that (I'll let others decide). -- 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/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Status in ufw source package in Impish: Fix Committed Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
Tested 0.36-6ubuntu1 on focal. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I didn't test on an iSCSI system so won't add verification-done-focal at this time, but I think the testing is probably sufficient for that (I'll let others decide). -- 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/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Status in ufw source package in Impish: Fix Committed Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. [Test Steps] * Install Ubuntu on an iSCSI (or other network-based) root filesystem. (eg, Oracle Cloud's bare-metal 'BM.Standard1.36' shape.) * sudo ufw enable * Observed: system may stall immediately if no prior iptables rules. (eg, iptables -A INPUT -p tcp -s 169.254.0.2 --sport 3260 -j ACCEPT) * Expected: system continues working. * sudo reboot * Observed: system boot stalls once ufw.service starts (see below.) * Expected: system boot should move on. [Regression Potential] * Potential regressions would be observed on ufw start/reload, when iptables rules are configured. * The resulting iptables configuration has been compared before/after the change, with identical rules on both. [Other Info] * Fixed in Debian and Jammy. [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Tested 0.36-0ubuntu0.18.04.2 on bionic. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order and I spot-checked allowed and deny traffic. I was able to verify the this bug is fixed via the test steps. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port proto tcp ufw allow from 2.2.2.2 port proto tcp ufw allow from 1.1.1.1 port * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible.
[Touch-packages] [Bug 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
Tested 0.36-6ubuntu1 on focal. apt upgrade succeeded and after reboot the firewall came up with the expected rules in the expected order. I was able to verify the this bug is fixed via the test steps. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port proto tcp ufw allow from 2.2.2.2 port proto tcp ufw allow from 1.1.1.1 port * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt: * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt: ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt: [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
I've looked at this issue again in reference to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 and while I still cannot reproduce, I plan to change to the following (I won't ship the commented out lines of course): [Unit] Description=Uncomplicated firewall Documentation=man:ufw(8) #DefaultDependencies=no #Before=network.target Before=network-pre.target Wants=network-pre.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/lib/ufw/ufw-init start quiet ExecStop=/lib/ufw/ufw-init stop [Install] WantedBy=multi-user.target This removes DefaultDependencies=no so that 'sysinit' will be pulled in and changes the single 'Before=network.target' to instead have Before=network-pre.target and Wants=network-pre.target. This won't help people who have different firewall software installed (like some of the comments), but should make startup more robust (eg, for those needing something from sysinit) while still allowing it to come up before the network. ** Bug watch added: Debian Bug tracker #990834 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990834 -- 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: Invalid 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 1946804] Re: ufw breaks boot on network root filesystem
Ah, I hadn't checked that yet. Yes, please feel free to do the Impish SRU and the 0.36.1-2 that I just uploaded to Debian will float into 'J' after it opens. -- 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/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: New Status in ufw source package in Bionic: New Status in ufw source package in Focal: New Status in ufw source package in Hirsute: New Status in ufw source package in Impish: New Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. Functional tests summary Attempted: 22 (3339 individual tests) Skipped: 0 Errors: 0 [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
For Impish, lets update debian/master, then I'll upload there and sync to Ubuntu. -- 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/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: New Status in ufw source package in Bionic: New Status in ufw source package in Focal: New Status in ufw source package in Hirsute: New Status in ufw source package in Impish: New Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. Functional tests summary Attempted: 22 (3339 individual tests) Skipped: 0 Errors: 0 [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05 8d d8 00 00 08 00 [
[Touch-packages] [Bug 1946804] Re: ufw breaks boot on network root filesystem
I merged the changes into master. Thanks Mauricio! ** Changed in: ufw Status: New => Fix Committed -- 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/1946804 Title: ufw breaks boot on network root filesystem Status in ufw: Fix Committed Status in ufw package in Ubuntu: New Status in ufw source package in Bionic: New Status in ufw source package in Focal: New Status in ufw source package in Hirsute: New Status in ufw source package in Impish: New Bug description: [Impact] A system with rootfs on iSCSI stops booting when ufw.service starts. The kernel logs iSCSI command/reset timeout until I/O fails and the root filesystem/journal break. The issue is that ufw_start() sets the default policy _first_, then adds rules _later_. So, a default INPUT policy of DROP (default setting in ufw) prevents further access to the root filesystem (blocks incoming iSCSI traffic) thus any rules that could help are not loaded (nor anything else.) [Fix] The fix is to set default policy after loading rules in ufw_start(). That seems to be OK as `ip[6]tables-restore -n/--noflush` is used, and per iptables source, that only sets the chain policy. This allows the system to boot due to the RELATED,ESTABLISHED rule, that is introduced by before.rules in INPUT/ufw-before-input chain. The comparison of `iptables -L` before/after shows no differences (verified on a local rootfs); `run_tests.sh` has 0 skipped/errors. Functional tests summary Attempted: 22 (3339 individual tests) Skipped: 0 Errors: 0 [ufw info] # ufw --version ufw 0.36 Copyright 2008-2015 Canonical Ltd. # lsb_release -cs focal [Boot Log] [ 232.168355] iBFT detected. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Setting up software interface enp45s0f0np0 ... [ 254.644505] Loading iSCSI transport class v2.0-870. [ 254.714938] iscsi: registered transport (tcp) [ 254.780129] scsi host12: iSCSI Initiator over TCP/IP ... [ 255.433491] sd 12:0:0:1: [sda] 251658240 512-byte logical blocks: (129 GB/120 GiB) ... [ 256.379550] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) ... [ 266.620860] systemd[1]: Starting Uncomplicated firewall... Starting Uncomplicated firewall... ... [ 298.491560] session1: iscsi_eh_cmd_timed_out scsi cmd 310a6696 timedout [ 298.580803] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.656262] session1: iscsi_eh_cmd_timed_out scsi cmd 94ad9246 timedout [ 298.745237] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 298.745270] session1: iscsi_eh_abort aborting sc 310a6696 [ 298.899644] session1: iscsi_eh_abort aborting [sc 310a6696 itt 0x13] [ 298.985788] session1: iscsi_exec_task_mgmt_fn tmf set timeout [ 302.075554] session1: iscsi_eh_cmd_timed_out scsi cmd 1a9458b5 timedout [ 302.164786] session1: iscsi_eh_cmd_timed_out return shutdown or nh [ 314.107541] session1: iscsi_tmf_timedout tmf timedout [ 314.169797] connection1:0: detected conn error (1021) [ 314.232266] session1: iscsi_eh_abort abort failed [sc 310a6696 itt 0x13] [ 314.323531] session1: iscsi_eh_abort aborting sc 94ad9246 [ 314.399640] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.495578] session1: iscsi_eh_abort aborting sc 1a9458b5 [ 314.571554] session1: iscsi_eh_abort sc never reached iscsi layer or it completed. [ 314.664050] session1: iscsi_eh_device_reset LU Reset [sc 310a6696 lun 1] [ 314.755773] session1: iscsi_eh_device_reset dev reset result = FAILED [ 314.834736] session1: iscsi_eh_target_reset tgt Reset [sc 310a6696 tgt <...>] [ 314.954144] session1: iscsi_eh_target_reset tgt <...> reset result = FAILED [ 315.063456] connection1:0: detected conn error (1021) [ 315.125743] session1: iscsi_eh_session_reset wait for relogin [ 398.843556] INFO: task systemd:1 blocked for more than 120 seconds. ... [ 401.039006] INFO: task jbd2/sda1-8:2522 blocked for more than 123 seconds. ... [ 402.483917] INFO: task iptables-restor:2648 blocked for more than 124 seconds. ... [ 435.707549] session1: session recovery timed out after 120 secs [ 435.780058] session1: iscsi_eh_session_reset failing session reset: Could not log back into <...> [age 0] [ 435.920710] sd 12:0:0:1: Device offlined - not ready after error recovery [ 436.003563] sd 12:0:0:1: [sda] tag#105 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK cmd_age=169s [ 436.015520] sd 12:0:0:1: rejecting I/O to offline device [ 436.134354] sd 12:0:0:1: [sda] tag#105 CDB: Read(10) 28 00 00 05
[Touch-packages] [Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
Olivier, yes, I shouldn't be assigned. Ian, you're right the profile is
suboptimal (it's also old so likely needs updating).
Do note that this is a separate named profile and evince (and if this is
put in an abstraction, anything that uses the abstraction) only has the
`/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,` rule which
means that it is able to run the 'snap' command (needed since everything
in /snap/bin points to /usr/bin/snap) which at the time I wrote the
profile meant that access to this socket was needed as part of snap run.
IIRC, snapd should be protecting certain actions by uid connecting to it
(eg, you are root or not), but it has been a while since I've looked at
that. Evince is not a snap though so if snapd does any checks on 'is the
client a snap' then those would fail and evince would be able to do
whatever a non-root user could do with the 'snap' command via the
socket.
For snap run, we can see that the snap_browser profile limits what can
be used with 'run' since (at the time I wrote the comment) 'snap run'
required being able to look at the meta/snap.yaml of the specific snap.
This 'works' (worked?) but is brittle since if snap run changed to lift
this requirement (eg, 'snap run' just passed the name of the unresolved
symlink to snapd over the socket and let snapd start the snap, perhaps
via userd, etc) then this falls apart.
The profile was put up as an example as what could be done at the time without
any help from snapd. I never particularly cared for it cause it was brittle and
not designed. I'm not sure how to fix this, but here are some thoughts:
* evince is just executing stuff from /snap/bin (probably via the system's
xdg-open). Assuming xdg-open, the system's xdg-open (or whatever evince is
using to decide and launch the default browser) could itself be fixed in Ubuntu
to launch a different command that behaved better. This wouldn't necessarily
fix other distros (though this is the evince profile in Debian and Ubuntu, so
*technically*, if you got this change (to presumably xdg-open) into them, you
could update the evince profile in them accordingly)
* In lieu of that, if the profile still worked as intended, snapd could be
hardened to look to check more than if the connecting process is root or a
snap; it could also see if it is running under a non-snap profile, then limit
access to the socket API accordingly. This has drawbacks and could break people
who have written custom profiles similar to what I presented.
* I suppose an alternative approach would be to have symlinks in /snap/bin for
things that are registered as browsers (or just the default browser) point to a
designed snap command. Eg:
/snap/bin/firefox -> /usr/bin/snap # keep the
existing one too
/snap/bin/default-browser-is-a-snap -> /usr/bin/snap-browser # name is
illustrative, TBD
Now firefox, chromium, opera, brave, etc snaps registers themselves as
being capable of being a default browser with snapd, then snapd
registers with the system that /snap/bin/default-browser-is-a-snap is
the default browser (so system utilities like xdg-open don't need to
change) and /usr/bin/snap-browser is written to be safe (eg, only able
to 'snap run' the configured default browser, nothing else) and apparmor
profiles are adjusted to have `/{,snap/core/[0-9]*/}usr/bin/snap-browser
Uxr,` (or similar). The /snap/bin/default-browser-is-a-snap path is
illustrative and there isn't really a need for it at all. Could simply
perhaps have snapd register /usr/bin/snap-browser as the default browser
on the system (it now needs to know what snapd configured as the default
browser snap though) and forego the symlink.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1794064
Title:
Clicking a hyperlink in a PDF fails to open it if the default browser
is a snap
Status in apparmor package in Ubuntu:
Confirmed
Status in evince package in Ubuntu:
Triaged
Bug description:
This is related to bug #1792648. After fixing that one (see discussion
at https://salsa.debian.org/gnome-team/evince/merge_requests/1),
clicking a hyperlink in a PDF opens it correctly if the default
browser is a well-known application (such as /usr/bin/firefox), but it
fails to do so if the default browser is a snap (e.g. the chromium
snap).
This is not a recent regression, it's not working on bionic either.
ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: evince 3.30.0-2
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Sep 24 12:28:06 2018
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-07-02 (813 days ago)
InstallationMedia: Ubuntu 16.04 LTS
[Touch-packages] [Bug 1794064] Re: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap
** Changed in: evince (Ubuntu) Assignee: Jamie Strandboge (jdstrand) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1794064 Title: Clicking a hyperlink in a PDF fails to open it if the default browser is a snap Status in apparmor package in Ubuntu: Confirmed Status in evince package in Ubuntu: Triaged Bug description: This is related to bug #1792648. After fixing that one (see discussion at https://salsa.debian.org/gnome-team/evince/merge_requests/1), clicking a hyperlink in a PDF opens it correctly if the default browser is a well-known application (such as /usr/bin/firefox), but it fails to do so if the default browser is a snap (e.g. the chromium snap). This is not a recent regression, it's not working on bionic either. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: evince 3.30.0-2 ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5 Uname: Linux 4.18.0-7-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Sep 24 12:28:06 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2016-07-02 (813 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: evince UpgradeStatus: Upgraded to cosmic on 2018-09-14 (9 days ago) modified.conffile..etc.apparmor.d.abstractions.evince: [modified] mtime.conffile..etc.apparmor.d.abstractions.evince: 2018-09-24T11:35:41.904158 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1794064/+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 1933117] Re: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule
** Also affects: ufw (Ubuntu) Importance: Undecided Status: New ** Changed in: ufw (Ubuntu) Status: New => In Progress ** Changed in: ufw (Ubuntu) Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- 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/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: In Progress Bug description: UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- -- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw insert 1 reject from 1.0.0.0/8 to any port 22 ufw insert 2 allow from any to any port 22 ...which was later updated to be... ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp ufw insert 2 allow from any to any port 22 proto tcp yes | ufw delete 3 ...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible. A reboot is required to fix the issue, as it reloads the configuration to the expected order. To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1933117/+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
@cajicas215 - your comment is not helpful. If you look at the other comments in this bug, there has been nothing to fix in ufw. I suggest looking at the comments in this bug and seeing if any of the issues others have seen apply to you. If not, please report a new bug with steps to reproduce. -- 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: Invalid 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 1726856] Re: ufw does not start automatically at boot
@Fabian - your change both makes the firewall start after networking,
brings python into the boot process (which can slow down boot) and
changes the intent of 'systemctl stop ufw' from unloading the firewall
to disabling the firewall in the moment and forever in the future, which
is inappropriate ('systemctl stop' is supposed to stop the service until
someone runs 'systemctl start' again or reboot. 'systemctl disable' is
meant to prevent the service from starting on reboot. This might be fine
for your system, but it would not be appropriate as a default in ufw or
distributions. Also, this bug is in upstream ufw and you are reporting
an issue on Raspbian, who would supply the packaging for ufw. If you
still feel the change should be made, I suggest filing a bug with
Raspbian so they can change their packaging of ufw.
--
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:
Invalid
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 1934931] Re: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently
It is unclear from the description that this has anything to do with networking. Are there any firewall denials in the logs (eg, /var/log/ufw.log or /var/log/kern.log)? If you disable ufw (sudo ufw disable) does the problem go away? As an aside, IIRC, MS-Teams is not a lightweight application and I suspect this could be memory consumption unrelated to the firewall. ** 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/1934931 Title: (X)ubuntu 20.04: GUFW and MS-Teams slow down traffic intermittently Status in Gufw: Invalid Status in ufw package in Ubuntu: Incomplete Bug description: Thanks for Gufw! inxi -S output: Xubuntu standard LTS installation - Kernel: 5.4.0-77-generic x86_64 bits: 64 Desktop: Xfce 4.14.2 Distro: Ubuntu 20.04.2 LTS (Focal Fossa). GUFW 20.04.1, MS Teams 1.4.00.13653 (64-Bit) (all up to date at the time of this report). ** Problem: 250 Mbit LAN connection slowing down *intermittently*, but reproducible, to a crawl of 300 kbit or less if Gufw is activated parallel to MS teams. * Gufw is used with only basic settings provided after installation (in:denied/out:allowed and nothing else set, no further rules). * There has not to be any active call in teams, just running it seems to cause the problem after a while (<5 minutes). * After congestion for some time (minutes), the system may recover to full speed again, only to succumb again after a few minutes. * Other parallel running programs' connections are slowed down as well in accordance, e.g. parallel samba file sharing download is affected as well. * Stopping teams restores the connection speed after a short while (~1 minute). * Parallel connections to the LAN(router) are not inhibited, it is just the one computer. Teams seems to switch ports after restarting (UDP6/~34nnn-4). I set up a range to be allowed within ports used by teams (e.g. 3:5, allow in/outbound) to no avail, connections dropped still to low speed. Thanks and regards, Christoph To manage notifications about this bug go to: https://bugs.launchpad.net/gui-ufw/+bug/1934931/+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 1921350] Re: UFW hangs indefinitely on any action
There is another bug related to ansible in https://bugs.launchpad.net/ufw/+bug/1911637. I suggest following that one. Leaving this one as Expired. -- 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/1921350 Title: UFW hangs indefinitely on any action Status in ufw package in Ubuntu: Expired Bug description: When installing a new cloudserver (on Amazon EC2, if it makes a difference), UFW completely hangs on any command, for example ufw status. Interrupting it with Ctrl+C yields this backtrace: Traceback (most recent call last): File "/usr/sbin/ufw", line 130, in lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun) File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock fcntl.lockf(lock, fcntl.LOCK_EX) KeyboardInterrupt The line numbers are always the same. The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the Amazon image. I have not seen this bug on other servers. UFW is version 0.36. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+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 1909373] Re: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10
There isn't anything in the logs the indicates that there what happened. Do you have any other information? ** 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/1909373 Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 Status in ufw package in Ubuntu: Incomplete Bug description: dont upgrade ProblemType: Package DistroRelease: Ubuntu 18.04 Package: ufw 0.36-0ubuntu0.18.04.1 Uname: Linux 3.18.14-17162658-QB35446819 aarch64 ApportVersion: 2.20.9-0ubuntu7.21 Architecture: arm64 Date: Sat Dec 26 20:56:19 2020 Df: Filesystem 1K-blocks Used Available Use% Mounted on rootfs 24604780 19261268 5251352 79% / tmpfs1434188 1020 1433168 1% /dev Dmesg: ErrorMessage: installed ufw package post-installation script subprocess returned error exit status 10 PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, unpackaged PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, unpackaged RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: ufw Title: package ufw 0.36-0ubuntu0.18.04.1 failed to install/upgrade: installed ufw package post-installation script subprocess returned error exit status 10 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1909373/+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 1898696] Re: add some deliminiter between ipv4 and ipv6 in ufw status
Thanks you for the report. It is difficult to convey ipv4 vs ipv6 vs both in list form and currently ufw lists any ipv6 rules with '(v6)' as part of the To and From (as seen in your paste). It isn't clear to me how adding an 'IPv6' break would improve this... I'm going to mark this as wishlist while I think about it. Regarding the side note, the person who posted the question was unaware of https://bugs.launchpad.net/ufw/+bug/1880453 which speaks to future support (it isn't needed as ufw will use the nft backend if the system is configured to do so). ** Changed in: ufw (Ubuntu) Importance: Undecided => Wishlist ** Changed in: ufw (Ubuntu) Status: New => 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/1898696 Title: add some deliminiter between ipv4 and ipv6 in ufw status Status in ufw package in Ubuntu: Confirmed Bug description: "ufw status numbered" shows all the rules in one block, numbered from top to bottom. First are the ipv4 rules, then the ipv6. This has led to some irritation. A user asked how to add a IPv4 rule to the end of the list. https://answers.launchpad.net/ubuntu/+source/ufw/+question/692096 Inserting ipv6 rules to the correct position is not easy to understand https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1368411 My suggestion is to at least add some separator between the ipv4 and ipv6 rules in the output of "ufw status". A blank line, or a comment line (# IPv6 rules:) would be fine. This would indicate that not both rule lists, but only one of them, is applied to a connection. ## output suggestion: Status: active To Action From -- -- [ 1] 22/tcp ALLOW INAnywhere [ 2] 8080:8090/tcp ALLOW INAnywhere # mywww [ 3] WWW Full ALLOW INAnywhere # IPv6 rules: [ 4] 22/tcp (v6)ALLOW INAnywhere (v6) [ 5] 8080:8090/tcp (v6) ALLOW INAnywhere (v6) # mywww [ 6] WWW Full (v6) ALLOW INAnywhere (v6) ## system info ufw --version: ufw 0.35 side note But maybe this is irrelevant as long as the future plans of ufw are unclear. (https://answers.launchpad.net/ubuntu/+source/ufw/+question/692803) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1898696/+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 1911637] Re: Another app is currently holding the xtables lock
** Changed in: ufw Status: New => Triaged -- 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/1911637 Title: Another app is currently holding the xtables lock Status in ufw: Triaged Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: New Bug description: Version: ufw 0.36 (via Debian buster 0.36-1 deb-package) I'm using ufw together with fail2ban, and often I get an error while fail2ban is trying to ban an ip: ``` ERROR: initcaps [Errno 2] Another app is currently holding the xtables lock. Perhaps you want to use the -w option? ``` it seems that in utils.py, get_netfilter_capabilities(...) iptables is called without "-w" flag to wait for the table lock perhaps the checks should include this parameter to avoid leaving temporary tables behind (and breaking fail2ban, but thats a different story ...)? To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+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 1911637] Re: Another app is currently holding the xtables lock
Actually, in thinking about this, ufw could use 'iptables -w' under the hood. I recall having troubles with this approach when providing the fix for https://bugs.launchpad.net/ufw/+bug/1204579. I suggest following my advice in my last comment to avoid the issue while using 'iptables -w' is explored. -- 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/1911637 Title: Another app is currently holding the xtables lock Status in ufw: Triaged Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: New Bug description: Version: ufw 0.36 (via Debian buster 0.36-1 deb-package) I'm using ufw together with fail2ban, and often I get an error while fail2ban is trying to ban an ip: ``` ERROR: initcaps [Errno 2] Another app is currently holding the xtables lock. Perhaps you want to use the -w option? ``` it seems that in utils.py, get_netfilter_capabilities(...) iptables is called without "-w" flag to wait for the table lock perhaps the checks should include this parameter to avoid leaving temporary tables behind (and breaking fail2ban, but thats a different story ...)? To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+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 1911637] Re: Another app is currently holding the xtables lock
Thanks for the report. I read the ansible bug but this issue is actually coming from the underlying iptables tool. Something on the system is manipulating the firewall via iptables at the same time that the ufw command is being run. As described, this would happen with any firewall software. If only ufw is being used with ansible, perhaps ensure that the ufw commands are not being run in parallel. The upstream bug referenced docker, which will also manipulate the firewall with iptables; perhaps ensure that ufw configuration is applied before docker is started. I'm going to mark this bug as Invalid for now. Feel free to provide more information if you feel this is specific to ufw. ** Changed in: ufw (Ubuntu) Status: Confirmed => Invalid ** Changed in: ufw (Ubuntu) Status: Invalid => New -- 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/1911637 Title: Another app is currently holding the xtables lock Status in ufw: Triaged Status in ufw package in Ubuntu: Confirmed Status in ufw package in Debian: New Bug description: Version: ufw 0.36 (via Debian buster 0.36-1 deb-package) I'm using ufw together with fail2ban, and often I get an error while fail2ban is trying to ban an ip: ``` ERROR: initcaps [Errno 2] Another app is currently holding the xtables lock. Perhaps you want to use the -w option? ``` it seems that in utils.py, get_netfilter_capabilities(...) iptables is called without "-w" flag to wait for the table lock perhaps the checks should include this parameter to avoid leaving temporary tables behind (and breaking fail2ban, but thats a different story ...)? To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1911637/+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 1933828] Re: NTP servers from DHCP are not propagated to timesyncd
** Changed in: oem-priority Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1933828 Title: NTP servers from DHCP are not propagated to timesyncd Status in OEM Priority Project: New Status in network-manager package in Ubuntu: New Status in network-manager source package in Focal: New Bug description: Network manager gets NTP servers from DHCP but do not update timesyncd to use it which keeps using ntp.ubuntu.com. This is a problem on private networks which do not have access to public internet. On this type of network the configuration of timesyncd must be updated manually instead of inheriting the conf from the dhcp servers. This can be integrated with a NM dispatcher script such as below: etc/NetworkManager/dispatcher.d/10-update-timesyncd for example: ==8<=8<=8<=8<=8<== #! /usr/bin/bash [ -n "$CONNECTION_UUID" ] || exit INTERFACE=$1 ACTION=$2 case $ACTION in up | dhcp4-change | dhcp6-change) [ -n "$DHCP4_NTP_SERVERS" ] || exit mkdir -p /etc/systemd/timesyncd.conf.d/ cat< /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf [Time] NTP=$DHCP4_NTP_SERVERS RootDistanceMaxSec=15 EOF systemctl restart systemd-timesyncd ;; down) rm -f /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf systemctl restart systemd-timesyncd ;; esac ==8<=8<=8<=8<=8<== ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: network-manager 1.30.0-1ubuntu3 ProcVersionSignature: Ubuntu 5.11.0-18.19+21.10.1-generic 5.11.17 Uname: Linux 5.11.0-18-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Jun 28 14:08:52 2021 InstallationDate: Installed on 2020-05-31 (393 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Alpha amd64 (20200527) RebootRequiredPkgs: linux-image-5.11.0-20-generic linux-base SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.30.0 connected started full enabled enabled disabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1933828/+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 1938005] Re: ufw ignores rules
Recall that ufw uses connection tracking so if you add a deny rule, you may need to expire the connection tracking. One way to do this is to run: `conntrack -D -d ` (see man conntrack for details). -- 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/1938005 Title: ufw ignores rules Status in ufw package in Ubuntu: Incomplete Bug description: With my setting I shouldn't be able to surf web, but I can do it (without proxy/vpn) This problem happens after `iptables -F` and only way to solve it, is to reboot PC. I tried `ufw reload` , too ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ufw 0.36-7.1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Mon Jul 26 11:53:17 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2021-06-17 (38 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+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 1938005] Re: ufw ignores rules
/etc/default/ufw has: DEFAULT_OUTPUT_POLICY="ACCEPT" This means that all outgoing traffic is allowed. If you would like to change that, you can use: $ sudo ufw deny outgoing This will make it more difficult for you to manage the firewall since you'll have to add rules like: $ sudo ufw allow out to any port 53 and the like. Note, using 'ufw reload' may not work as expected if you are running iptables commands by hand underneath it. In those case, I suggest: $ sudo /lib/ufw/ufw-init flush-all $ sudo ufw disable $ sudo ufw enable Please report back. Thanks again for the report. ** 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/1938005 Title: ufw ignores rules Status in ufw package in Ubuntu: Incomplete Bug description: With my setting I shouldn't be able to surf web, but I can do it (without proxy/vpn) This problem happens after `iptables -F` and only way to solve it, is to reboot PC. I tried `ufw reload` , too ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ufw 0.36-7.1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Mon Jul 26 11:53:17 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2021-06-17 (38 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+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 1938005] Re: ufw ignores rules
Thank you for the bug report. You mentioned that the problem happens after running `iptables -F`. This command removes all the rules from the firewall (see man iptables) so it would be expected that the firewall would not work correctly after running this. I'm going to mark this as Invalid, but if you have more information, feel free to add it. ** Changed in: ufw (Ubuntu) Status: New => Invalid -- 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/1938005 Title: ufw ignores rules Status in ufw package in Ubuntu: Invalid Bug description: With my setting I shouldn't be able to surf web, but I can do it (without proxy/vpn) This problem happens after `iptables -F` and only way to solve it, is to reboot PC. I tried `ufw reload` , too ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: ufw 0.36-7.1 ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22 Uname: Linux 5.11.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Mon Jul 26 11:53:17 2021 EcryptfsInUse: Yes InstallationDate: Installed on 2021-06-17 (38 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.ufw: 2021-07-25T22:22:29.221649 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1938005/+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 1937036] [NEW] package initramfs-tools 0.136ubuntu6.6 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status
Public bug reported: I think my boot partition is full. Idea: could it have a pre-install script that checks if the install partition has space, and if not then provide a link to some documentation on how to find and purge old kernels? ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-59-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Jul 21 09:50:16 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-04-21 (90 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.6 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.6 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package focal -- 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/1937036 Title: package initramfs-tools 0.136ubuntu6.6 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: I think my boot partition is full. Idea: could it have a pre-install script that checks if the install partition has space, and if not then provide a link to some documentation on how to find and purge old kernels? ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.6 ProcVersionSignature: Ubuntu 5.8.0-59.66~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-59-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Jul 21 09:50:16 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-04-21 (90 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.6 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.6 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1937036/+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 1929212] Re: package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
Was getting similar errors on on subsequent `sudo apt upgrade`s - worked around by freeing boot space as suggested in https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1899907 -- 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/1929212 Title: package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: Crash report appeared immediately after wake-up from suspend On Ubuntu 20.04.2 LTS. ``` $ apt-cache policy initramfs-tools initramfs-tools: Installed: 0.136ubuntu6.4 Candidate: 0.136ubuntu6.5 Version table: 0.136ubuntu6.5 500 500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages *** 0.136ubuntu6.4 100 100 /var/lib/dpkg/status 0.136ubuntu6 500 500 http://gb.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu focal/main i386 Packages ``` ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.4 ProcVersionSignature: Ubuntu 5.8.0-50.56~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-50-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.17 AptOrdering: intel-microcode:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Fri May 21 10:39:27 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-04-21 (29 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.5 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1929212/+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 1929212] [NEW] package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status
Public bug reported: Crash report appeared immediately after wake-up from suspend On Ubuntu 20.04.2 LTS. ``` $ apt-cache policy initramfs-tools initramfs-tools: Installed: 0.136ubuntu6.4 Candidate: 0.136ubuntu6.5 Version table: 0.136ubuntu6.5 500 500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages *** 0.136ubuntu6.4 100 100 /var/lib/dpkg/status 0.136ubuntu6 500 500 http://gb.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu focal/main i386 Packages ``` ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.4 ProcVersionSignature: Ubuntu 5.8.0-50.56~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-50-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.17 AptOrdering: intel-microcode:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Fri May 21 10:39:27 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-04-21 (29 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.5 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package focal -- 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/1929212 Title: package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: Crash report appeared immediately after wake-up from suspend On Ubuntu 20.04.2 LTS. ``` $ apt-cache policy initramfs-tools initramfs-tools: Installed: 0.136ubuntu6.4 Candidate: 0.136ubuntu6.5 Version table: 0.136ubuntu6.5 500 500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu focal-updates/main i386 Packages *** 0.136ubuntu6.4 100 100 /var/lib/dpkg/status 0.136ubuntu6 500 500 http://gb.archive.ubuntu.com/ubuntu focal/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu focal/main i386 Packages ``` ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.4 ProcVersionSignature: Ubuntu 5.8.0-50.56~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-50-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.17 AptOrdering: intel-microcode:amd64: Install NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip Date: Fri May 21 10:39:27 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2021-04-21 (29 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.5 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.4 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1929212/+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 1921350] Re: UFW hangs indefinitely on any action
Thanks you for reporting a bug. Are there other ufw commands running at the same time? Eg, what is the output of: $ ps auxww|grep ufw ** 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/1921350 Title: UFW hangs indefinitely on any action Status in ufw package in Ubuntu: Incomplete Bug description: When installing a new cloudserver (on Amazon EC2, if it makes a difference), UFW completely hangs on any command, for example ufw status. Interrupting it with Ctrl+C yields this backtrace: Traceback (most recent call last): File "/usr/sbin/ufw", line 130, in lock = create_lock(lockfile=lockfile, dryrun=pr.dryrun) File "/usr/lib/python3/dist-packages/ufw/util.py", line 1112, in create_lock fcntl.lockf(lock, fcntl.LOCK_EX) KeyboardInterrupt The line numbers are always the same. The platform is Ubuntu Server 20.04 (Ubuntu 20.04.2 LTS), from the Amazon image. I have not seen this bug on other servers. UFW is version 0.36. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1921350/+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 1914816] Re: ufw not logging if it decides to stop all traffic ? Confused
Thanks for the additional information! :) ** Changed in: ufw (Ubuntu) Status: Incomplete => Invalid -- 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/1914816 Title: ufw not logging if it decides to stop all traffic ? Confused Status in ufw package in Ubuntu: Invalid Bug description: Sorry, this is going to be a very bad report. Here's what I did: - installed gufw and enabled it, no rules, just default incoming=deny outgoing=accept - rebooted - Ethernet says it connected - no network access; ping 1.1.1.1 fails - launch gufw, and it says it's disabled (the whole firewall) - I think eventually I figured out that iptables had been emptied and INPUT chain set to DROP After many travails, I captured a piece of dmesg output as the system was booting, and I think it shows ufw trying to check IPv6 status and deciding to stop everything. At least logging (which was set to full in gufw) suddenly stops. In network manager, I've tried to say "ignore IPv6". I'm not sure if this trouble is related to fiddling with the "only work if IPv4 is enabled" check-box, which seems to have a ToolTip that is exactly backwards. My ISP does not give IPv6 service. I've tried many settings of the IPv6 drop-down in System Settings / Network GUI, setting and clearing the IPv4 and IPv6 required check-boxes, etc. So, I'm totally confused, but I think the log shows that logging suddenly stops (from full to zero), which must mean ufw detected some condition that made it empty out the iptables and set everything to DROP ? If so, ufw should have logged a message saying it was doing so, and I don't see such a message. So, if I'm right, at least this is a feature request that ufw should log a message when it decides to stop all IPv4 or IPv6 traffic and/or stop logging and/or wipe out all rules. Sorry about the mess of a report. I'm using Kubuntu 20.10, gufw 20.10.0-0ubuntu1, ufw 0.36-7 ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: ufw (not installed) ProcVersionSignature: Ubuntu 5.8.0-41.46-generic 5.8.18 Uname: Linux 5.8.0-41-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: KDE Date: Fri Feb 5 20:35:18 2021 InstallationDate: Installed on 2021-02-03 (2 days ago) InstallationMedia: Kubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) SourcePackage: ufw UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1914816/+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
