An alternative workaround is uninstalling the cloud-init package. If
this package is not installed, cloud-init cannot be found, so the error
does not happen.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I think the problem is in the postinst script, line 295:
cloud_id=""
if command -v "cloud-id" > /dev/null ; then
cloud_id=$(cloud-id)
fi
The third line should rather be:
cloud_id=$(cloud-id || true)
This way, an error reported by the cloud-id command is treated just
I can also confirm that installing the keyutils package fixes the
problem (on Ubuntu 20.04).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1734700
Title:
mounting CIFS share failure (cifs_mount
We are affected by this bug, too.
A more stable workaround than modifying /lib/systemd/system/ovsdb-
server.service might be adding an overrides file (so that the fix will
survive package upgrades).
On our affected systems, we added a file /etc/systemd/system/ovsdb-
We don’t have any systems with Xenial any longer, so I can’t test there.
In fact, just this week we decommissioned the Bionic-based system where
I originally discovered this bug, so even there, I can’t test it any
longer.
--
You received this bug notification because you are a member of Ubuntu
Thank you, Mauricio! I can confirm that your test kernel for Bionic
(4.15.0-110.111+lp1867916.1) fixes the problem for me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867916
Title:
Regression in
Hi Mauricio,
according to my Bash history, I used the following two commands to
create the Bcache device:
make-bcache -B -b 524288 -w 524288 -o 8192 /dev/vg0/vg2-backend
make-bcache -C -b 4194304 -w 4096 -o 8192 /dev/vg1/vg2-cache
I think the reason why I used this block size was that the MD
Hi Mauricio,
I have attached the requested information.
Best regards,
Sebastian
** Attachment added: "lp1867916-queue_block_size.seb"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867916/+attachment/5379837/+files/lp1867916-queue_block_size.seb
--
You received this bug
Hi Mauricio,
I can confirm that your patched kernel fixes the problem for me on
Bionic (kernel 4.15).
Thanks for your help!
-Sebastian
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1867916
Title:
Hi Mauricio,
thanks for your support. I have attached the requested information to
the bug. I had to pseudomize some of the logical volume names because
they are considered sensitive, but I did so in a consistent way so the
structure should still be clear.
So that you don’t have to look through
** Attachment added: "block device hierarchy"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867916/+attachment/5347771/+files/lp1867916.1.out
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Mauricio,
there is the problem that this tarball contains an awful lot of
sensitive data, some of that personal data that is protected under the
GDPR.
Maybe you could tell me which specific parts / sections you are
interested in, so that I can anonymize and upload them.
Thanks,
Sebastian
--
Public bug reported:
After upgrading from kernel 4.15.0-88 to 4.15.0-91 one of our systems
does not boot any longer. It always crashes during boot with a kernel
panic.
I suspect that this crash might be related to Bcache because this is the
only one of our systems where we use Bcache and the
I guess there is only one case where the current "fix" would help. If
someone had some library providing libungif in a different place, the
broken symlinks in /usr/lib might take precedence, thus hiding the
correct files.
In my opinion, removing the dangling symlinks is a slight improvement on
I tested the package from trusty-proposed, but I am not sure whether the
issue can be considered fixed.
In fact, the dangling symlinks have been removed, but they have not been
added in the right place. This means that software depending on libungif
will still not compile.
The question is,
I updated the Impact and Test Case sections of this bug's description. I
hope this better fits the purpose of describing the actual impact on
users.
** Description changed:
Impact
==
- libgif-dev in Ubuntu 14.04 LTS depends on libgif4 and has these symlinks:
- /usr/lib/libungif.a ->
The workaround suggested by Ikuya Awashiro (setting the gateway for the
route to 0.0.0.0) does not work for me. The problem persits even after
applying this workaround. The VPN connection is only established when
all static routes are deleted from the configuration.
--
You received this bug
** Patch added: "bareos-openssl.patch"
https://bugs.launchpad.net/ubuntu/+source/bareos/+bug/1611348/+attachment/4738164/+files/bareos-openssl.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This problem exists because the build-process of the package compiles
against GnuTLS insteaed of OpenSSL. The encryption features are only
supported when compiling with OpenSSL.
In order to change from GnuTLS to OpenSSL, the following changes have to
be applied to the source tree:
diff -Naur
I think that unlike the bug title and description suggest, this bug is
not limited to IPv6. I am having the same problem with FreeRADIUS when
RADIUS packets are received over IPv4. This problem is fixed by the
Kernel from trusty-proposed, too.
Actually, this problem looks a lot like a regression
@sds: Yes, they exist, but in /usr/lib, while they should be in
/usr/lib/x86_64-linux-gnu (depending on the platform). As libgif.* is
not in /usr/lib, the symbol links point to files that do not exist.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Are there any plans to backport this change to giflib-4.1.6-11 on
trusty? Considering that trusty is still going to be supported for more
than three years, it might make sense to backport this bugfix.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
*** This bug is a duplicate of bug 1508510 ***
https://bugs.launchpad.net/bugs/1508510
I can confirm that this bug is a duplicate of bug #1508510 and that the
kernel from -proposed fixes the problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Public bug reported:
I am running the 3.13 series kernel on Ubuntu 14.04 LTS (Trusty Tahr).
A change introduced in version 3.13.0-66.108 of this kernel breaks UDP
sockets under certain circumstances. The effect is that the recvfrom
operation returns with an error, setting errno to EFAULT, even
I verified that the bug is fixed in version 2.1.12+dfsg-1.2ubuntu8.1 and
that the upgrade process (restart) works as intended.
Thank you very much for your efforts in fixing this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I verified that the bug is fixed in version 2.1.12+dfsg-1.2ubuntu8.1 and
that the upgrade process (restart) works as intended.
Thank you very much for your efforts in fixing this bug.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1406105
Title:
Broken logrotate script in
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1406105
Title:
Broken logrotate script in freeradius-2.1.12+dfsg-1.2ubuntu8 on
Public bug reported:
The freeradius-2.1.12+dfsg-1.2ubuntu8 on Ubuntu 14.04 LTS (Trusty Tahr)
has a bug in the logrotate script (/etc/logrotate.d/freeradius):
The command /etc/init.d/freeradius reload is used for reloading
freeradius after its logfile(s) have been rotated. However, in Ubuntu
I just realized that there is a better solution for the logrotate
script: By using service freeradius reload, the script will work when
Upstart is used but also when the traditional init script is used.
** Patch added: Revised patch for the logrotate script
Public bug reported:
The freeradius-2.1.12+dfsg-1.2ubuntu8 on Ubuntu 14.04 LTS (Trusty Tahr)
has a bug in the logrotate script (/etc/logrotate.d/freeradius):
The command /etc/init.d/freeradius reload is used for reloading
freeradius after its logfile(s) have been rotated. However, in Ubuntu
I just realized that there is a better solution for the logrotate
script: By using service freeradius reload, the script will work when
Upstart is used but also when the traditional init script is used.
** Patch added: Revised patch for the logrotate script
I think that the originally described problem is in fact caused by the
bug described in #20. Unless we expect every archive mirror to support
ranged requests (which IMHO is a bit much to ask), the 406 error needs
to be handled properly. Even if a mirror supports ranges, the
implementation in the
*** This bug is a duplicate of bug 1307473 ***
https://bugs.launchpad.net/bugs/1307473
I am not sure whether this bug is really a duplicate of #1307473.
I experienced the problems described in this bug report without CPU
pinning being used. I might add that I had the impression that Windows
Public bug reported:
In Ubuntu 14.04 LTS on x86_64 I am experiencing the following bug in
libgif-dev 4.1.6-11:
Symbol links for libungif.a, libungif.la, and libungif.so are created in
/usr/lib that point to libgif.a, libgif.la and libgif.so.4.1.6
respectively. However, these files are not in
This problem seems to appear when a file has been partially downloaded
to /var/lib/apt/lists/partial and the server does not support request
ranges. Here is the error I got when running aptitude update and the
corresponding HTTP requests / responses:
[...]
Err http://de.archive.ubuntu.com
I tested the following packages from precise-proposed on Ubuntu 12.04 LTS
(amd64) and they work fine for me:
openvswitch-brcompat_1.4.0-1ubuntu1.5
openvswitch-common_1.4.0-1ubuntu1.5
openvswitch-controller_1.4.0-1ubuntu1.5
openvswitch-datapath-dkms_1.4.0-1ubuntu1.5
I tested the following packages from precise-proposed on Ubuntu 12.04 LTS
(amd64) and they work fine for me:
openvswitch-brcompat_1.4.0-1ubuntu1.5
openvswitch-common_1.4.0-1ubuntu1.5
openvswitch-controller_1.4.0-1ubuntu1.5
openvswitch-datapath-dkms_1.4.0-1ubuntu1.5
I do not think that it is the same bug as originally described in bug
#1088160. This bug was an issue with the build system. However, it might
be the same problem that that one comment
(https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1088160/comments/2)
to that bug described.
--
You
I can confirm the the new version (from the PPA) fixes the problem for
me.
Thank you very much for the quick solution!
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openvswitch in Ubuntu.
https://bugs.launchpad.net/bugs/1125611
I do not think that it is the same bug as originally described in bug
#1088160. This bug was an issue with the build system. However, it might
be the same problem that that one comment
(https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1088160/comments/2)
to that bug described.
--
You
I can confirm the the new version (from the PPA) fixes the problem for
me.
Thank you very much for the quick solution!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1125611
Title:
DKMS brcompat
Public bug reported:
On Ubuntu 12.04.2 LTS, after an automatic upgrade from openvswitch
1.4.0-1ubuntu1.3 to openvswith 1.4.0-1ubuntu1.4 the brcompat support
does not work any longer.
The brcompat kernel module can be build, installed, and loaded, but
openvswitch-brcompatd will not start with the
Public bug reported:
On Ubuntu 12.04.2 LTS, after an automatic upgrade from openvswitch
1.4.0-1ubuntu1.3 to openvswith 1.4.0-1ubuntu1.4 the brcompat support
does not work any longer.
The brcompat kernel module can be build, installed, and loaded, but
openvswitch-brcompatd will not start with the
Peter, yes I was trying to install the nvidia-current from the quantal
repository, which has the dependency on the newer X version.
A few weeks ago I updated the affected system to precise. The version of
the nvidia-current package in precise had the same problems as the one
in lucid. In fact it
It might be fixed in 295.49, however there is no way to test this,
because 295.49 is only available in quantal while I am running lucid. In
fact I cannot install it manually either, because it depends on xserver-
xorg-core (= 2:1.10.99.901) and the newest version available in lucid
is
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/986371
Title:
Regression in nvidia-graphics-drivers causes freezes in combination
with gnome-screensaver
To manage notifications about this bug go
Public bug reported:
The security update of the nvidia graphics driver causes a problem on my
system (GeForce 8800 GTS):
When the screen is locked (using gnome-screensaver) the screen freezes
for about 30 seconds. The same thing happens, when the screen is
unlocked.
This problem appeared after
The problem of shutting down the virtual machines consists of two parts:
If a init-script is used, libvirtd might be killed, before the shutdown
command has been sent to the virtual machines. If the pre-stop script in
the libvirt-bin upstart job is used or a new upstart job starting on
stopping
The problem of shutting down the virtual machines consists of two parts:
If a init-script is used, libvirtd might be killed, before the shutdown
command has been sent to the virtual machines. If the pre-stop script in
the libvirt-bin upstart job is used or a new upstart job starting on
stopping
Public bug reported:
Binary package hint: ethtool
PROBLEM:
I am running Ubuntu 8.04 in a Xen DomU.
To fix network performance issues, the line post-up /usr/sbin/ethtool
-K eth0 tx off is needed for the virtual ethernet device within the
/etc/network/intefaces file.
Usually this works fine,
51 matches
Mail list logo
