Valid point, though arguably a different bug. Looks like mimicking the old
sysvinit behaviour might be quite tricky. Maybe a comment in the stub
rc.local would do? Unless we can do something clever with unit run
conditions...
On Wed, 28 Dec 2022, 18:50 Michael Tokarev, <1950...@bugs.launchpad.net>
** Patch added: "Report exit status to systemd after daily activities"
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/691050/+attachment/5598352/+files/apt.systemd.daily.patch
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscrib
Also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972872
** Bug watch added: Debian Bug tracker #972872
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972872
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in U
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778878 relevant,
though thread seems to have been hijacked.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/691050
Title:
Dail
Ironically, 12 years later in 22.04, /usr/lib/apt/apt.systemd.daily
doesn't seem to indicate success or failure to systemd either, which
means you can't use e.g. journalctl -p err as a "one stop shop" to find
things that are failing on system :(
** Bug watch added: Debian Bug tracker #778878
ht
The bug has been periodically tripping me up for years, but recently I
discovered that it has basically stopped my elderly uncle from using
Libreoffice (which defaults to GTK file picker on Xubuntu at least) on
bionic. Priority really needs to be higher, at least if the intent is
for Ubuntu to be u
This is due to "ProtectHome=yes" in the .service file; the workaround is
to add:
[Service]
ProtectHome=no
In e.g. /etc/systemd/system/fstrim.service.d/allow-home.conf
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linu
The other option in u-a might be to split Unattended-Upgrade::Allowed-
Origins into "Automatic origins" and "permitted origins", so only
packages in the former will be automatically installed, but upgraded
dependencies could be pulled from the latter if required?
--
You received this bug notifica
Digging a bit further - this machine was manually dist-upgraded on
30-May-2021 (it has -updates enabled, but is set to install only
security updates automatically.) That update pulled in libglvnd
1.3.2-1~ubuntu0.20.04.1 (source for libegl1, libglvnd0, etc.)
To upgrade to webkit2gtk 2.34.6-0ubuntu0
I suppose there's an argument to be made that if the user is prepared to
periodically manually install non-security updates, then they should be
prepared to check for held back security updates too. I tend to work
from the command-line so don't know what the GUI interface(s) allow and
indicate in t
Fixed by
https://github.com/iputils/iputils/commit/e2e9a2dd4639924614bdbee43907a49134e8da19
it seems.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iputils in Ubuntu.
https://bugs.launchpad.net/bugs/1892108
Title:
ping pr
This commit actually didn't reliably fix this bug, but given the length
of time here, I've opened a new bug #1950906
--
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/1451797
T
Public bug reported:
The fix for bug #1451797 introduced /lib/systemd/system/rc-
local.service.d/debian.conf with the intent that rc.local would always
run after the network was fully online. However, it only has an After=
line, without actually pulling in network-online.target. Systemd docs
say:
I think the long test case in #5 now works. Note that later versions of
crun have worked around the problem:
https://github.com/containers/crun/pull/672
Still worth fixing, though, I think, as it is likely to cause further
problems as more code starts to use close_range.
--
You received this bug
Still working out kinks in the above, but here's a simpler one. Needs
running in an nspawn container again (steps 1-2 above); should either
succeed (no output) or print "function not implemented", but without
seccomp support nspawn will block it and it will print "not permitted"
#include
#include
It's not going to be simple I'm afraid, at least for the original
problem! "scmp_sys_resolver close_range" will quickly test whether
current seccomp has support for close_range (prints "-1" if not
supported, "436" otherwise - at least on x86_64.) Ubuntu seccomp
maintainers have been pretty happy SR
Can confirm rebuilding seccomp in focal with the relevant bits of the
above two commits allows me to whitelist close_range in systemd-nspawn,
solving my problem.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ub
https://github.com/seccomp/libseccomp/pull/322/ (or at least parts of
it) probably required too.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1944436
Title:
Please ba
Public bug reported:
Please backport support for the "close_range" syscall .. may be as
simple as cherrypicking
https://github.com/seccomp/libseccomp/commit/01e5750e7c84bb14e5a5410c924bed519209db06
from upstream. I've hit problems running buildah in a systemd-nspawn
container, but this will prob
I'm seeing something similar to this (messages more like those in
underlying debian bug report) - in this case triggered by a script which
sshs in (invoking unison) twice in quick succession. Underlying hardware
is an ARM board which may a little slow, don't know if that helps to
trigger race?
I'm
It's just possible that the commit linked may fix
https://github.com/systemd/systemd/issues/12313 as well ..
** Bug watch added: github.com/systemd/systemd/issues #12313
https://github.com/systemd/systemd/issues/12313
--
You received this bug notification because you are a member of Ubuntu
To
LGTM!
--
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/1883447
Title:
nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to
focal in containers
Status in
Ah, looks like I don't need to do anything for focal's systemd-nspawn
other than add openat2 to SyscallFilters= in the .nspawn file. With
that, and the seccomp from the PPA, everything seems OK - thank you!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded pack
OK, this is getting complicated. seccomp 2.5.0 and systemd-nspawn both
have bugs which when combined cause most/all syscall filters to actually
be disabled! See
https://github.com/seccomp/libseccomp/issues/273#issuecomment-668458070
So I think your new packages are probably OK, but as they pull in
Attached is a trivial test case, needs to be run in a container by a
container manager that uses seccomp for syscall filtering (e.g. nspawn.)
It should either silently succeed or print "openat2: Function not
implemented" ; if seccomp combined with the container manager (e.g.
nspawn) blocks the ope
Hmm, I tested with libseccomp2_2.5.1-0ubuntu0.20.04.1_test4_amd64.deb
from the PPA and it doesn't seem to fix the openat2 problem - just
realised I should have added I'm now using focal not bionic for my
container host.. will try to investigate why once I'm back on my desktop
machine.
--
You rece
Any progress on this? I've just run into it again, and due to my
appalling memory have spent two hours debugging and now discovered my
own bug report again :/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubunt
** Attachment added: "/etc/initramfs-tools/scripts/local-top/btrfs-lvm"
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1848180/+attachment/5447426/+files/local-top.script
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed t
OK, attached are some initramfs scripts:
local-top.hook -> /etc/initramfs-tools/hooks/btrfs-lvm
local-top.script -> /etc/initramfs-tools/scripts/local-top/btrfs-lvm
I've tried to make them reasonably generic, the root fs is examined on
initramfs creation, component btrfs devices extracted and tes
I'm seeing this on focal as well. Running vgchange when the initramfs
crashes to shell no longer seems to work - it just hangs. I have to add
break=mount to kernel command line and do it there. Now working on
hacking something into /etc/initramfs-tools/scripts/local-top/ -
@Gabriele, that should al
Still broken in bionic in 2020!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/882878
Title:
With IPv6 disabled, openssh will not forward X connections
Status in portable
This has just happened on yet another machine. It seems to occur if
there's a snapshot of root volume in existence? Any chance of a fix?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.ne
Actually, I recommend not looking at 2.5.0 or master until
https://github.com/seccomp/libseccomp/issues/273 is fixed! Definitely a
security issue.
** Bug watch added: github.com/seccomp/libseccomp/issues #273
https://github.com/seccomp/libseccomp/issues/273
--
You received this bug notificati
Public bug reported:
The version of libseccomp2 in bionic does not know about the openat2
syscall.
In my particular usecase, I was trying to run podman/buildah in an
nspawn container, using fuse-overlayfs. This leads to peculiar failure
modes as described in this issue:
https://github.com/contai
This bug also seems to generate "Assertion
'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at src/basic
/time-util.c:55, function now(). Aborting" in various places if you try
to boot an existing 20.04 container on bionic with systemd-nspawn.
--
You received this bug notification because
https://patchwork.kernel.org/patch/10756415/ is the upstream kernel
patch it seems.
** Summary changed:
- nspawn on arm blocks _time64 syscalls, breaks upgrade to focal in containers
+ nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal
in containers
** Description chan
Thinking about it, it probably only applies to arm, or at least to 32
bit archs (I think 64bit archs use 64-bit time already.) I'll try and
find a reference for that ..
** Summary changed:
- nspawn blocks _time64 syscalls, breaks upgrade to focal in containers
+ nspawn on arm blocks _time64 sysca
Public bug reported:
This may only affect armhf, but I can't see why it should.
Recent Linux kernels introduced a number of new syscalls ending in
_time64 to fix Y2038 problem; it appears recent glibc, including the
version in focal, test for the existence of these. systemd-nspawn in
bionic (237-
This has just bitten me again on yet another machine - is it ever going
to be fixed? If it helps I suspect it's something to do with having
snapshots kicking around ..
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ub
Do you also see slow shutdowns? One of my servers which has other
problems with this patch (bug #1870783) has been seen to get stuck
shutting down / rebooting showing a message about (I think) lvmetad
(hard to tell due to very small server console truncating message) ..
systemd eventually times it
Just reported my own bug #1870783 - my server appears to hang (without
above message), but eventually successfully boots after ~ 180 secs.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.
Public bug reported:
2.02.176-4.1ubuntu3.18.04.2 causes at least one of my servers to hang on
boot for ~ 3 minutes. adding debug=y to kernel command line seems to
show the last script was init-top/udev. Downgrading to
2.02.176-4.1ubuntu3 resolves the problem.
Possibly related to bug #1859829 and
Any news on this? Recent upgrade has removed my patches to dnsmasq, and
I'm hitting this again. Still convinced the Ubuntu-specific patch to
systemd-resolved is flawed as well.
I will try to get brain back into gear to have at look at this all
again. If nothing else, would be good to SRU the dnsma
Just tested on bionic, looks good - thanks everyone!
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sy
OK, so my kernel didn't have seccomp support compiled in and systemd
just silently fails to set seccomp filters in that case.
Have now reproduced the bug on an armhf disco VM, and verified that the
package in proposed, 240-6ubuntu5.8 fixes it.
** Tags removed: verification-needed-disco
** Tags ad
OK, I've had a go, but oddly I can't reproduce this in a disco VM at the
moment, which makes testing the fix tricky..
--
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/1840640
@vorlon, will do my best to test the disco version, but I don't
currently have an ARM disco environment, and usual health battles mean
it'll probably be a struggle to set one up - I'll have a go though!
The bionic version I will of course be all over :)
--
You received this bug notification beca
Can't check at the moment, but details should have been added by apport.
Is it possible arm64 abi is different from armhf (32bit?)
On Thu, 3 Oct 2019, 22:41 Dan Streetman,
wrote:
> I'm having trouble reproducing this on a Bionic nspawn container on
> arm64; what host release, and container rele
Looks like this may finally have been fixed in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774560
** Bug watch added: Debian Bug tracker #774560
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774560
--
You received this bug notification because you are a member of Ubuntu
Touc
Would it be possible to add a flag to AvahiPublishFlags to allow the
application to request the required behaviour on a per-service basis? I
can't see any options for Pidgin that don't require pretty radical
restructuring of its codebase (more discussion at
https://bugs.launchpad.net/ubuntu/+source
** Bug watch added: github.com/lathiat/avahi/issues #243
https://github.com/lathiat/avahi/issues/243
** Also affects: avahi via
https://github.com/lathiat/avahi/issues/243
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
I found a mailing list post which mentioned this, but no replies:
https://lists.freedesktop.org/archives/avahi/2010-March/001863.html
It actually causes problems for Pidgin in certain circumstances, see bug
#1841621.
--
You received this bug notification because you are a member of Ubuntu
Touch
The "obvious fix" (attached) does indeed solve the problem - haven't
done enough testing as of yet to be sure there are no weird
consequences.
** Description changed:
I have machine with the following nspawn file:
--
[Network]
MACVLAN=laneth0
[Exec]
PrivateUsers=false
--
Public bug reported:
I have machine with the following nspawn file:
--
[Network]
MACVLAN=laneth0
[Exec]
PrivateUsers=false
--
if I start it with systemctl start systemd-nspawn@name, all works as
expected.
If I start manually with systemd-nspawn -M name -b, I seem to correctly
get a new network
Test packages in case anyone wants them:
https://www.dropbox.com/sh/gxuy14k1t2chwbu/AABKX2idDrGu2R3Fwio0DAOTa?dl=0
--
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/1840640
Tit
Public bug reported:
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls the
latter whenever a userspace program calls sync_file_range. I'm guessing
systemd-nspawn doesn't know this, because the follow code consistently
fai
Public bug reported:
XFCE & Xubuntu use in their menu files, which
python-xdg currently (all current versions) does not handle correctly:
https://gitlab.freedesktop.org/xdg/pyxdg/issues/12
I think the fix is as simple as
--- Menu.py.a 2019-06-23 17:44:24.992850139 +0100
+++ Menu.py.b 2019-
I'm seeing this in a slightly different situation .. I'm running an xpra
server which starts its own pulseaudio server; something to do with
running Chrome and attempting to play video randomly results in
everything in /dev/shm getting deleted, which leads the shm errors
reported above.
I made sur
** Bug watch added: Red Hat Bugzilla #1671964
https://bugzilla.redhat.com/show_bug.cgi?id=1671964
** Also affects: lvm2 via
https://bugzilla.redhat.com/show_bug.cgi?id=1671964
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ub
** Description changed:
This is a weird corner case. Extending an lvmraid(7) type1 mirror for
the second time seems to result in the mirror legs not getting synced,
*if* there is another type1 mirror in the vg. This reliably reproduces
for me:
# quickly fill two 10G files with random
Public bug reported:
This is a weird corner case. Extending an lvmraid(7) type1 mirror for
the second time seems to result in the mirror legs not getting synced,
*if* there is another type1 mirror in the vg. This reliably reproduces
for me:
# quickly fill two 10G files with random data
openssl en
Confused to see no movement on this bug?
The logical thing seemed to be add another case to /usr/share/initramfs-
tools/scripts/local-top/lvm2 calling lvchange_activate with no
parameters, but it seems that doesn't work - does
activation/auto_activation_volume_list need to be set in lvm.conf
perha
https://github.com/systemd/systemd/issues/4927 is probably the relevant
upstream bug
** Bug watch added: github.com/systemd/systemd/issues #4927
https://github.com/systemd/systemd/issues/4927
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
The patch "resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-
with.patch" for bug #1727237 seems to be the root cause of my problems
(now reported separately in bug #1785383.)
As the patch changes the transaction restart logic it may be worth the
OP rebuilding without that patch and retesting.
The fix for this bug is causing me problems with name resolution on the
LAN using dnsmasq as an upstream server:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1785383/comments/4
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subs
Reverting the patch "resolved-Mitigate-DVE-2018-0001-by-retrying-
NXDOMAIN-with.patch" solves this problem for me. My best guess is that
the following patch segment changes some key logic:
@@ -388,12 +388,12 @@ static int dns_transaction_pick_server(DnsTransaction *t)
{
if (!server)
On further investigation this seems to be specific to the Ubuntu version
of systemd 237. I cannot reproduce it with the upstream release.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpa
Amend to test case:
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo -S /test/
--host-record=test.test,${SUBNET}.1
Cannot reproduce bug in systemd 239, but would be good to know which
commit fixed the problem for cherry picking purposes.
--
You received this bug notification because y
Public bug reported:
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty
answer for a domain it is authoritative for. systemd-resolved seems to
get confused by this in certain circumstances; when using the stub
resolver and requesting an address for which there are no recor
Public bug reported:
While trying to backport 2.79 to trusty, I discovered it now needs
eddsa.h from nettle-dev, which only seems to have been added in version
3.1:
https://git.lysator.liu.se/nettle/nettle/commit/6907bbacd6da270aea6cd9d51eb9c0e25c17d520
** Affects: dnsmasq (Ubuntu)
Importan
@xnox:
Yes, on further investigation it looks like these might well be
different bugs - OTOH the repeated issuance of queries to the upstream
server, and the confusion about the server capabilities is very similar,
which suggests a problem in the same code path may be being triggered. I
will creat
Installing libss-resolve works around the problem for me - is there a
reason this is not installed by default on Ubuntu, per upstream's
recommendations?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https:
Hmm, my case seems to be caused by a dnsmasq bug - if there are no
answers, it doesn't return an EDNS0 OPT record even if there was one in
the query. This seems to be confusing systemd-resolved.
Not sure what is causing @ahasenack's issue - the pcap shows the
upstream DNS consistently not returnin
Have a filed an upstream report:
https://github.com/systemd/systemd/issues/9785
** Bug watch added: github.com/systemd/systemd/issues #9785
https://github.com/systemd/systemd/issues/9785
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is s
I'm see this just trying to resolve names on my local LAN:
Aug 02 17:50:40 beelink systemd-resolved[6697]: Processing incoming packet on
transaction 52812. (rcode=SUCCESS)
Aug 02 17:50:40 beelink systemd-resolved[6697]: Server doesn't support EDNS(0)
properly, downgrading feature level...
Aug 02
Another thread relevant, at least for the gnucash aspect of this bug:
https://lists.gnucash.org/pipermail/gnucash-user/2018-March/075769.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gtk+2.0 in Ubuntu.
https://bugs.laun
Linking Jonathan's mailing list thread for reference:
https://lists.gnucash.org/pipermail/gnucash-user/2018-April/076587.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gtk+2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1
Public bug reported:
Version: 1.10.6-2ubuntu1
Ubuntu release: 18.04
I've just had a fun few minutes wondering why I couldn't disable NM
using "systemctl disable network-manager.service". Looks like the real
unit file is NetworkManager.service, and the former is a symlink.
Per systemd.unit(5), "u
Also seeing this on Ubuntu 14.04. Mixed network, have an if-up.d script
to restart minidlna - but sometimes it gets restarted after an IPv6
address has been obtained but before an IPv4 address is configured.
** Also affects: network-manager
Importance: Undecided
Status: New
** Also affe
79 matches
Mail list logo
