Public bug reported:
After upgrading to 15.04 from 14.10, Samba no longer starts at boot. I
suspect it's related to the switch to systemd, as attempting to set it
to start using the systemd tools results in a bunch of error messages:
root@c1:~# systemctl enable samba
Synchronizing state for samba
Can't find any systemd specific init scripts for samba, either:
root@c1:/etc/systemd# find . | grep samba
root@c1:/etc/systemd# find . | grep smb
root@c1:/etc/systemd# find . | grep nmb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to s
Huh, I'm seeing the same behaviour as you now:
nergdron@c1:~⟫ ls -l /lib/systemd/system/samba.service
lrwxrwxrwx 1 root root 9 Apr 3 14:32 /lib/systemd/system/samba.service ->
/dev/null
nergdron@c1:~⟫ sydi 0u^C
130 nergdron@c1:~⟫ sudo -i
[sudo] password for nergdron:
root@c1:~# systemctl start
I wonder if this is a shaw mirror issue, since I'm definitely getting
that version on utopic from their mirror:
⟫ apt-cache showpkg awscli
Package: awscli
Versions:
1.2.9-2
(/var/lib/apt/lists/ubuntu.arcticnetwork.ca_dists_utopic_universe_binary-amd64_Packages)
Description Language:
⟫ apt-cache policy awscli
awscli:
Installed: (none)
Candidate: 1.2.9-2
Version table:
1.2.9-2 0
500 http://ubuntu.arcticnetwork.ca/ utopic/universe amd64 Packages
So that looks fine.
Added in ca.archive.ubuntu.com, and yeah:
395 upgraded, 19 newly installed, 2 to remove and 0
Public bug reported:
Having problems fetching files using the version of python-requests in
14.04. It works fine in 14.10 and more recent releases, so it appears to
be a bug in the older version of python-requests that 14.04 has. This
affects things like salt-stack, which leverage python-requests
Yeah, the fact that this isn't even being worked on since this problem
was reported over a year ago is pretty embarrassing. It definitely seems
like critical Ubuntu server issues are largely ignored.
--
openldap install bare bones need default DIT separate package
https://bugs.launchpad.net/bugs/
Checking `chkutmp'... *** stack smashing
detected ***: ./chkutmp terminated
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xb76cb255]
/lib/i386-linux-gnu/libc.so.6(+0x10420a)[0xb76cb20a]
./chkutmp[0x8048b15]
./chkutmp[0x8048ce
I'm experiencing this in 15.04. With the change to systemd, the pm-utils
scripts are no longer run when the system resumes after suspend.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bug
Also:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725284
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779412
** Bug watch added: Debian Bug tracker #725284
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725284
** Bug watch added: Debian Bug tracker #779412
http://bugs.debian.o
I've given up on hdparm.conf now. As noted in #27, it seems that systemd
and udev/udisks2 is the way to go, but it's not clear how exactly.
Here's what I've done. This bug report isn't the ideal place to document
it, but I can't find a better place for now. Maybe it'll help someone
who finds it th
Ok, updated to the latest libvirt packages from PPA:dnjl/virtualization.
Now, the migrate, then suspend/resume suggestion works for me. Still
less than ideal, as it kills the whole "live migration" thing, but at
least it doesn't totally kill my VMs anymore.
--
VM is suspended after live migrate i
Here's an interesting addition to this problem:
In my cluster, one system is based on a core2duo CPU, while the other is
based on an i7 920 CPU. When the VM is originally started on the i7,
migration doesn't work. When it's originally started on the core2, it
does. From this, I'm guessing that the
*** This bug is a duplicate of bug 463684 ***
https://bugs.launchpad.net/bugs/463684
Why is this marked as a duplicate of a documentation bug? There are
documentation issues here, to be sure, but this is also a "useful
configuration missing by default" bug, which isn't covered by #463684.
--
I'm not as enraged as others here, but I agree with Yannick. If we had a
debconf based base configuration for cn=config, and removed it, then it
should be put back in. Clearly having it would be less problematic for
most users than not having it.
--
openldap sections in ubuntu server guide not up
Docs look better, but they also serve to highlight that the base config
should be more fleshed out. That's a lot of non-trivial steps to get to
a point where you can actually use your slapd install for something.
--
openldap sections in ubuntu server guide not updated for packages in karmic
https
Any update on when we'll see an updated package for this issue?
--
open-iscsi user-space does not match kernel module version
https://bugs.launchpad.net/bugs/289470
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to open-iscsi in ubuntu.
--
I definitely agree about introducing into Karmic. That way there'll be
some wider usage and testing before the next LTS.
--
[needs-packaging] Fedora Directory Server for Ubuntu
https://bugs.launchpad.net/bugs/27463
You received this bug notification because you are a member of Ubuntu
Server Team,
Tim:
Is it possible to get packages for jaunty into your repo? I'm getting
errors trying to rebuild the packages on jaunty/amd64. It freaks out and
generates a ton of errors trying to compile this:
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-DBUILD_NUM=\"2009.161.2056\"
Hey Kai-Cheung,
Sorry I wasn't more explicit, but I *did* rebuild the required libraries
from Tim's repo for jaunty. It still doesn't build properly for me. ;)
I suspect that perhaps the build-deps on the packages aren't totally
accurate, since I'm building on a fresh jaunty install inside a VM,
I'm afraid I don't recall exactly. Maybe it was just accidental.
--
Patches for documentation
https://bugs.launchpad.net/bugs/318495
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to autofs in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubu
I'm seeing behaviour that looks like this on karmic/amd64, only a
suspend/resume doesn't "fix" the VM. It stays hard locked. I can connect
to it on the virtual serial console or via VNC, and it shows what was
there before the migration, but it never unlocks and starts working.
--
VM is suspended
Public bug reported:
This is a bug reported in Debian and Redhat, which I'm currently seeing
on fresh installs of Ubuntu/karmic. The details of my problem generally
match the Debian bug report, which I'll link here.
ProblemType: Bug
Architecture: amd64
Date: Fri Nov 27 15:12:25 2009
DistroRelease
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/36181383/Dependencies.txt
** Bug watch added: Debian Bug tracker #533436
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533436
** Also affects: drbd8 (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533
The Redhat bug has a more thorough investigation of the issue, as well
as a potential patch we can use. The Debian bug has a partial workaround
using kpartx.
--
Unable to use use LVM with DRBD block devices as PV
https://bugs.launchpad.net/bugs/489398
You received this bug notification because yo
/etc/lvm/lvm.conf filter suggestion from redhat bug works well,
actually. After filtering out the block device my drbd device is based
on, lvcreate works as expected.
--
Unable to use use LVM with DRBD block devices as PV
https://bugs.launchpad.net/bugs/489398
You received this bug notification b
This was with a hardy/amd64 guest OS. I haven't tried any other guests,
because the bulk of our VMs are supposed to be LTS installs.
--
VM is suspended after live migrate in Karmic
https://bugs.launchpad.net/bugs/448674
You received this bug notification because you are a member of Ubuntu
Server
27 matches
Mail list logo
