Yep, adding
Environment=SFS_MOUNTPOINT=/sys/kernel/security/apparmor/
to
/lib/systemd/system/apparmor.service
Fixes the bug.
--
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
Adding set -x and calling this directly:
Cosmic:
. /lib/apparmor/functions
is_container_with_internal_policy
+ local ns_stacked_path=/sys/kernel/security/apparmor/.ns_stacked
+ local ns_name_path=/sys/kernel/security/apparmor/.ns_name
+ local ns_stacked
+ local ns_name
+ '[' -f /sys/kernel/securit
In Cosmic /lib/systemd/system/apparmor.service pointed to "/etc/init.d/apparmor
start"
This had some code, but it was not triggered:
if [ -x /usr/bin/systemd-detect-virt ] && \
systemd-detect-virt --quiet --container && \
! is_container_with_in
Since I started seeing this in libvirt There might be reasons that is done that
way but this affects me and probably other use cases e.g. if I install libvirt:
$ apt install libvirt-daemon-system
$ aa-status | grep libvirt
On my test systems the containers do not get any profile loaded:
$ aa-
In that container that has no profiles at all I can explicitly load them.
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd
$ systemctl restart libvirtd
makes it show up correctly
1 processes are in enforce mode.
/usr/sbin/libvirtd (1146)
But why is it missing in the first place
Apparmor is disabled in LXD containers now !?!
Compare aa-status after spawning a new container.
root@d-testapparmor:~# aa-status
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
/snap/core/6673/usr/lib/snapd/snap-confine
/snap/core/6673/usr/lib/snapd/snap
On s390x it only uses sysinfo for systemd-detect-virt,
src/basic/virt.c:306:r = get_proc_field("/proc/sysinfo", "VM00
Control Program",
WHITESPACE, &t);
but there also the Host UUID is exposed:
$ cat /proc/sysinfo
VM00 UUID:0804001f-c45f-4345-994f-9fec048e822e
There
*** This bug is a duplicate of bug 1823093 ***
https://bugs.launchpad.net/bugs/1823093
This was initially triggered by:
https://code.launchpad.net/~xnox/ubuntu-seeds/+git/ubuntu-seeds/+merge/363541
Which was matching cleanups we did earlier this year and again in Malta.
But that there was fa
Now that we know that we can drop all bug ubuntu-meta task, marking the
others invalid.
** Changed in: multipath-tools (Ubuntu)
Status: New => Invalid
** Changed in: multipath-tools (Ubuntu)
Status: Invalid => Triaged
** Changed in: multipath-tools (Ubuntu)
Importance: Undecided
Yep, once checking the right and up to date branches it seems clear.
I found [1], subscribing xnox here as well.
This change was on late February, there was no ubuntu-meta update since
then so the issue wasn't triggered.
I think we'd want to undo the seed change, but in a fashion so that what
xno
Germinate [2] clearly points at the seeds.
bin:multipath-tools src:multipath-tools why:Ubuntu.Disco server seed
bin:multipath-tools-boot src:multipath-tools why:Ubuntu.Disco
server-ship-live seed
The second I saw before in the seeds [1], but where exactly is the first
line listed here within
Change introduced in Ubuntu-meta in 1.431 [1]
But since that usually only reflects the seeds that must be from there somehow.
[1]: https://launchpad.net/ubuntu/+source/ubuntu-meta/1.431
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subsc
root@d-upgr:~# apt remove multipath-tools -s
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
ibverbs-providers kpartx libaio1 libfreetype6 libibverbs1 libnl-3-200
libnl
Thanks Rbalint for fixing that.
Since a triggering change in qemu is in at least >=Bionic and was reported to
even affect continuous unattended upgrades there would you considering SRUing
your changes as needed?
I added tasks for all releases, but set >=Bionic to high to to that being an
issue i
Thank you Timo!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bugs/1795857
Title:
enable CONFIG_DRM_BOCHS
Status in kmod package in Ubuntu:
Fix Released
Status in linux packag
@Timo - Ack, this should be enabled again. And if really still an issue
for PPC then a different solution than to disable it should be evaluated
(can we do arch specific blakclisting?).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscr
This is in all newer versions of iproute2 (newer than Xenial), setting
the general task to Fix Released
** Changed in: iproute2 (Ubuntu)
Status: Invalid => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to i
I'm subscribed here in case there is anything I'm needed, but the qemu task is
actually invalid as the change won't be there.
Further I assigned it to rbalint to reflect that he is working on this in u-u.
** Changed in: unattended-upgrades (Ubuntu)
Assignee: (unassigned) => Balint Reczey (rb
** Description changed:
+ [Impact]
+
+ * If an update has a new conffile at a path that in a former version was
+a directory like
+ old: /a/b/c
+ new: a/b
+Here b is the new file name and was a directory in the old version.
+Then unattended upgrades breaks on installing such
Fix might be in qemu (add even more special cases) or in unattended
upgrades (to properly handle or at least not die). Added a bug task for
that.
** Description changed:
As reported on
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1820291/comments/20
We fixed an issue and we added work
Public bug reported:
As reported on
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1820291/comments/20
We fixed an issue and we added workrounds since basic mv_conffile coudn't
handle it and did all sort of upgrade tests.
That all worked fine and moved the conffile.
It was now reported th
Thanks Dan[FS] for working on this!
I tested the PPA of Dannf and can also confirm it works fine, I extended the
SRU template of this bug to be slightly more readable and SRU acceptable (more
details in regression considerations).
Furthermore I added a testcase for the mode when external DHCP se
I have seen such errors related to OpenVZ 6 - you can take a look at bug
1814124 and bug 1811580 for that if it applies to you.
If that is true check for the workarounds in those buge for a short term
resolution, long term you should ask your provider to update your hosting
environment.
If your
*** This bug is a duplicate of bug 1811580 ***
https://bugs.launchpad.net/bugs/1811580
Same discussion and more in bug 1811580 marking as dup to have people
finding this bug all get to the same main bug.
** This bug has been marked a duplicate of bug 1811580
systemd fails to start sshd at
See lightdm and gpu-manager services in
http://paste.ubuntu.com/p/5QyzgMKhmr/ for an example how that looks like
from a guests POV.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bug
Thanks cascardo for testing power8 already.
This came up in bug 1823152 as well and made me aware of this.
If qemu is not run in commandline most frontends set something else than "-vga
std" therefore I wasn't aware. But I can confirm seeing the issue.
I think I can test x86 quite easily, is the
in: mesa (Ubuntu Ee-series)
Status: New => Triaged
** Changed in: qemu (Ubuntu Ee-series)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
No feedback on the Debian ML [1] yet, how do we go on with this knowing
that our Freeze is in 8 days?
@CJwatson - are you going to drive that in Debian according to Feedback (or the
lack thereof) to your mail and then sync it to Disco in time?
For now I'll assume so - no offense please, I just ne
Just to be prepared I added an MP for this at [1].
But I agree to cjwatson that we should (if possible) either revert this in
Buster+Disco or none of them to not split up the behavior of different releases
even more.
Never the less, one might want to peek at the change and or play with the PPA
FYI - Up for discussion in the scope of Debian-Buster at [1].
[1]: https://lists.debian.org/debian-devel/2019/04/msg00010.html
--
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
I filed this bug at Debian as well => https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=926229
** Bug watch added: Debian Bug tracker #926229
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926229
** Also affects: openssh (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926
Colin was so kind to also find this reference [1] in Debian.
Which asks about the same revert, but not yet for it affecting VMWare - instead
it seems it also conflicts with "iptables -m tos" as well.
I'll bring it up with VMWare, but if also conflicting with some iptables
options that would be on
Until resolved - as a landing page (I'll put that in the description as well):
The summary for the workarounds for now is:
You can configure your /etc/ssh/ssh_config permanently
Host *
IPQoS lowdelay throughput
Or per command via:
$ ssh -o IPQoS=throughput user@host
---
Per the other bugs
@Frank - that is good for you and thanks for confirming my assumptions.
But it is unfortunate for openssh :-/
** Bug watch added: github.com/hashicorp/vagrant/issues #10730
https://github.com/hashicorp/vagrant/issues/10730
--
You received this bug notification because you are a member of Ubun
@cjwatson - I subscribed you as you usually look after ssh(d) - have you
heard about that issue before or have any special recommendation
already?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs
Interesting and maybe related
https://communities.vmware.com/thread/590825
https://github.com/vmware/open-vm-tools/issues/287
https://bugzilla.redhat.com/show_bug.cgi?id=1624437
The TL;DR of those is that VMWare would have issues with the AF21 QoS flag.
Does your client run in VMWare by chance?
Maybe the keepalive defaults got changed?
All past references to the issue refer to some sort of keepalive to avoid the
issue.
For example [1]
Be aware that some suggestions on [1] configure the sever, while your
issue is on the client side (at least that is where the upgrade
happened.
You could
FYI - Might be:
- bug 1811580
Or broken /var/run / /run connection which is related to
- https://askubuntu.com/questions/1109934
- https://serverfault.com/questions/941855
You might pickup some hints about the issue in general there.
As paride said let us know if you identified a bug in Ubuntu it
[Duplication]
No duplication of that functionality in the Archive in general or main in
particular.
[Embedded sources and static linking]
This package does not contain embedded library sources.
This package does not statically link to libraries.
It does create static .a libs for its -dev package,
I filed bug 1820232 (now a dup) only to realize this was already approved.
Under the usual terms I'd want the ack on this MIR to be used to (re-)promote
it once we pull it back in by seeding mailman3.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
*** This bug is a duplicate of bug 1597439 ***
https://bugs.launchpad.net/bugs/1597439
Thanks Andreas, also I now have taken a look at the demotion.
The only reason to demote is was that the need from unity to pull it in went
away.
There was no explicit demotion reason filed.
Therefore we ca
Thanks Steve,
as people have explained above the problem with the "if the information is
available elsewhere" argument is, that very long living systems have rotated
out the logs that contained the initial boot. This is the extra value this
wants to give back to the users.
** Changed in: rsyslo
Not yet subscribing the MIR Team until the FTBFS is fixed and it was
clarified why it was demoted since the former MIR.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zeromq3 in Ubuntu.
https://bugs.launchpad.net/bugs/1820232
Public bug reported:
[Availability]
zeromq3 exists in Universe already. Current version in disco is 4.2.5-2 and it
builds in amd64, arm64, armhf, i386, ppc64el, s390x.
It produces two binary packages: a library runtime, and its corresponding
development package. We need the runtime libzmq5 in mai
Public bug reported:
[Availability]
The package is already universe for quite a while and build/works fine so far.
It is for example already used for
https://lists.canonical.com/mailman3/postorius/lists/
OTOH it is a library that can/could be used for much more than just the
mailman3 stack.
It
Thanks Sebastien for re-assigning.
And thank you Nathan, for taking the time to report this bug and helping
to make Ubuntu better. I appreciate the quality of this bug report and
I'm sure it'll be helpful to others experiencing the same issue.
I agree to the triage made so far, but in that case t
Per former discussion, better safe than sorry - added a FFe request to
the description and subscribed the release-team.
** Description changed:
+ [FFe]
+ * (re-)introduce a feature to ensure the initial (boot time) kernel
+messages are preserved
+ * This existed up to Trusty (upstart) but
@xnox - thanks for your ping, I agree if we would have worked on this in Vivid
or at least Xenial.
But being so late I'd think to ask for an ack by the Release team is not wrong.
I thought here "better safe than sorry" somewhat applies.
OTOH fortunately the change itself isn't very invasive to an
Hi,
it has been released for Cosmic already.
Some tests were blocking it for Bionic but I resolved those already.
It should be released the next time an SRU member will look at this.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribe
I understand the back and forth between the packages responsibility here.
In fact I was involved in a similar problem for ntp that was discussed here:
- https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1689585/comments/7
- https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1689585/comments/12
B
Added an apparmor task for its similarity to bug 1689585 but set it
immediately to Won't Fix (as we did there). But having apparmor people
getting notified might help with the continuation of this discussion.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded pa
Might I ask - how much is this bug related or a dup to bug 1819074?
--
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/1815101
Title:
netplan removes keepalived configuration
Is this a dup to bug 1815101 ?
--
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/1819074
Title:
Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-
network
Adding other components involved.
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
As soon as something isn't urgent it falls off everyones lists :-/
I have found this old bug (again) in my notes, felt embarrassed and converted
the suggestion of xnox into an MP that we can ack and push to early 19.10 then
(hopefully not forgetting it again).
We probably will have to rebase the
Tests were just flaky as assumed, retried and good now
** Changed in: libseccomp (Ubuntu Bionic)
Status: Incomplete => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.la
The PPA was built against -proposed so I had to enable that to install all libs.
That done the 19.0.0~rc6-1ubuntu0.1 with the set affinity change reverted works
quite nicely.
It would be great to get that into Ubuntu 19.04 until the involved
upstreams agreed how to proceed with it and we can then
Hi Timo,
I tried to test with the mesa from ppa:canonical-x/x-staging
But there is a dependency issue in that PPA - I can't install all packages from
there.
It seems most of the X* packages will need a transition for the new mesa and
those are not in this ppa right now.
Installing all that I can
** Also affects: mesa (Ubuntu Disco)
Importance: Medium
Status: Confirmed
** Also affects: qemu (Ubuntu Disco)
Importance: Undecided
Status: Triaged
** No longer affects: qemu (Ubuntu Disco)
** Changed in: mesa (Ubuntu Disco)
Status: Confirmed => Triaged
** Changed in
Finally if your dhcp server might just be flaky/unresponsive then this is the
correct behavior.
Please fix it on the dhcp server setup then OR follow the discussion at bug
1776013 which leads to
https://www.freedesktop.org/software/systemd/man/systemd.network.html#CriticalConnection=
But really
Would you have the full journal from the time you started the guest (we
should see it getting a lease from dnsmasq) until the guest complains
about it being lost?
Please attach those from Guest AND Host as I'd like to check if dnsmasq
in the host and/or systemd-networkd in the guest had any.
Best
Your configuration looks as if you bridges the guests to an external connected
bridge (br0)
I assume your guests get DHCP from something else on 172.18.232.11/25 and not
from the hosts DNSMASQ is that right?
If that is true please provide logs from the actual dnsserver.
--
You received this bu
Ah BTW - to keep things clean please just start one guest until the
issue occurs and then a second as discussed.
Do not start/stop other guests at the time
Do not have other guests up before you start
Do not restart services for all of the time you track this
That also should help to keep the log
Thanks Daniel and MarcAndre for chiming in here.
Atfer thinking more about it I agree to Daniel that actually mesa should honor
and stick with its affinity assignment.
For documentation purpose: the solution proposed on the ML is at
https://lists.freedesktop.org/archives/mesa-dev/2019-February/2
@Ubuntu-Desktop Team (now subscribed) - is there a chance we can revert [1] in
mesa before it will be released with Disco for now. That would be needed until
an accepted solution throughout the stack of libvirt/qemu/mesa is found?
Otherwise using GL backed qemu graphics will fail as outlined in t
Testing as-is
$ ${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
failed to find preadv2
seccomp_load_filters failed with -1
1
Update to version in proposed:
$ sudo apt install libseccomp2/bionic-proposed
Reading p
Added improved test ordering to the description
** Description changed:
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefor
Testing as-is
(remember to clean old images if you have tested the ppa on the same system
before)
$ docker system prune -a
... Test steps ...
Step 8/8 : RUN ./test-statx test-file
---> Running in 60210feb0c2e
test-file: Operation not permitted
statx(test-file) = -1
The command '/bin/sh -c ./test
Public bug reported:
Hi,
Sorry to bother you - it seems we have this discussion every few months or so.
I was looking at this due to an SRU and I realized that the last 50-100 tests
on all architectures are currently failing.
http://autopkgtest.ubuntu.com/packages/s/systemd/bionic/amd64
http://a
This is outdated, lets close it in favor of focusing on new/recent
issues.
** Changed in: systemd (Ubuntu)
Status: New => Invalid
** Changed in: systemd (Ubuntu)
Status: Invalid => Opinion
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packag
@Brian - it was already meant to be marked verification-failed per comment #33
, so IMHO there is no hope anymore to get this verified.
Further there is work incoming for ua-tools in Xenial (and Trusty), for that
I'd really appreciate if this could be removed from proposed even sooner than
after
Piorities are a bit odd, eventually all packages affected (low prio as
they can't do much about it) actually depend on lightdm to resolve it
(prio medium) which depends on accountsservive to implement some shell-
filter feature (prio high).
TL;DR as there was a lot of discussion up to now:
- users
The Dup 1667113 had tracked some more affected packages - since all are
dupped on this bug here let me add those tasks here so that all
component owners are aware.
** Also affects: ceph (Ubuntu)
Importance: Undecided
Status: New
** Also affects: ifmail (Ubuntu)
Importance: Undecided
*** This bug is a duplicate of bug 857651 ***
https://bugs.launchpad.net/bugs/857651
** This bug has been marked a duplicate of bug 857651
Unable to hide users from login screen / user switcher
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
I also pinged jfh to make it part of the s390x related tracking
--
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.net/bugs/1813227
Title:
lvm2-pvscan services fails to start on S390X DPM
I saw [1] by xnox popping up, so he might work on this already. I have
pinged him to clarify.
[1]: https://code.launchpad.net/~xnox/ubuntu-seeds/+git/ubuntu-
seeds/+merge/363541
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to
If the change by xnox fixes your case then the resolution is to ship multipath
on those images.
@Lee - waiting for your answer if the services (and thereby the pvscan) works
after multipath is installed.
In general I think xnox might work on this then (not sure)?
I subscribed him to be aware as
Hi Lee,
thanks for the logs - once multipath is installed the devices are multipath
mapped.
But obviously at the time pvscan failed they were not.
I'd expect that after you have installed all dependencies for multipath
to work that then restarting lvm2-pvscan works fine.
Can you confirm that thi
Hi John,
the report has a lot of red herrings (all the error device is in use), but IMHO
in the log the error that you hit was.
Use of uninitialized value $reply in scalar chomp at
/usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66
That is a known and unfortunate issue, as it occurs ever
Hi Hrovje,
Thank you for taking the time to report this bug and helping to make
Ubuntu better.
The directory would usually be created for you on system start.
There were cases where users set /var to tmpfs or similar things eventually
breaking this.
You might take a look at [1] as that pretty m
All pre-checks and tests complete, and uploaded to the SRU review queue
** Changed in: libseccomp (Ubuntu Bionic)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
htt
://launchpadlibrarian.net/410848161/buildlog_ubuntu-bionic-amd64.libseccomp_2.3.1-2.1ubuntu5~ppa2_BUILDING.txt.gz
** Changed in: libseccomp (Ubuntu Bionic)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: libseccomp (Ubuntu Bionic)
Status: Triaged => In Pr
All pre-checks and tests complete, and uploaded to the SRU review queue
--
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/1815415
Title:
please update libseccomp for newer
Thanks for the reviews - I'll have to come up with some tests on my own
then ...
In general there already are build time tests and autopkgtests in the package.
So coverage of "old calls" for regressions is already good.
Fortunately the autopkgtests seem to be extendable for an explicit verificatio
I combined the requested changes in the PPA [1] and version ~ppa2 is
building now. Later autopkgtests will be kicked on bileto [2] to pre-
check those as well.
I updated the MP for re-review accordingly.
[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3640
[2]: https://bileto.ubu
Combining all those also allows us to take the changes (since they only
add definitions the only context they had were "each other) without any
backport noise.
** Description changed:
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Li
** Description changed:
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a
@Seth / @Tyler - Hi, you asked for the change, but I'd want to ask for
something as well :-) Do you have any testcases from your security work
that we could reuse here to check the SRU for SRU verification?
** Description changed:
+ [Impact]
+
+ * The libseccomp library provides an easy to use,
Public bug reported:
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to
support further new kernel syscall defines - this isn't even looking at HWE
kernels for Bionic, but "just" adding those which are there
Disco and Cosmic already contain those changes
** Also affects: libseccomp (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: libseccomp (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: libseccomp (Ubuntu)
Status: New => Fix Released
**
/+git/libseccomp/+merge/362906
** Tags added: server-next
** Changed in: libseccomp (Ubuntu Bionic)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp
Ok, tests worked fine for me - I added all I had as SRU template in the
bug description.
** Description changed:
+ [Impact]
+
+ * Some newer workloads fail due to libseccomp as in Bionic lacking
+ statx support
+
+ * This backports the syscall definitions for statx to Bionic to allow
+ to man
Hi I polished your patch a bit and I'm currently testing it in PPA [1].
If you can give it a try as well.
I have created an SRU Teamplate and more detailed test steps and will
add them once they hopefully succeed on the prepare PPA. Otherwise I'll
ping here for you to revisit the change.
[1]: htt
** Tags removed: server-triage-discuss
--
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/1812247
Title:
ssh-askpass(-gnome) fails for ssh-add -c: agent refused operation
Sta
I took a fresh Xenial (daily) as well as a Xenial of the release day and ran
the commands:
$ apt-get clean && apt-get autoclean && apt-get autoremove && apt-get update &&
apt-get upgrade && apt-get dist-upgrade && reboot
Obviously the updated different amounts of packages, but none did break
the
> Did you switch terminals in between or reset it?
No it was all in the same terminal - not even a re-login via ssh
> Those should not be related, it sounds more like a terminal screwup.
> Like, sometimes, at least in gnome-terminal, it reaches a point where
> readline and friends fail for some
Public bug reported:
Hi,
I saw this by accident and I'm not sure if it is a bug or if it just was a bad
config.
But I wanted to report to be sure this isn't missed.
I happened to do an apt upgrade like this:
$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Readin
Hi,
I took a fresh system and it had openssh-server installed right away (as it is
part of all the base images).
/var/run/sshd was at 0755 root:root already
I was wondering if the package install would kill the permission/ownership, so
I did
$ apt install --reinstall openssh-server
But things
@Rbalint - FYI the test hint is merged and active for now.
Since your fix will NOT bump the version of livecd-rootfs it will
continue to be hinted even after the fix, would you mind once this bug
here is resolved to open up an MP to remove the hint again?
--
You received this bug notification be
We checked what actually is the backend that the "ssh-add -c" is trying to
reach.
First we thought that should be the ssh-agent spawned for gnome-keyring-daemon
[1]
In PS that is visible as:
1 1000 4029 1 20 0 656132 15860 - SLl ? 0:24
/usr/bin/gnome-keyring-daemon --dae
901 - 1000 of 1238 matches
Mail list logo
