The above mentioned fix/workaround didn't work for me for some reason.
Adding "vmxnet" to the list modules to be included in the initrd did
work for me though.
--
network interface does not come up after installing open-vm-tools
https://bugs.launchpad.net/bugs/289921
You received this bug notific
Works for me as well (ESXi 3.5 host).
--
open-vm-source doesn't build
https://bugs.launchpad.net/bugs/278711
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.c
Travis,
I think it was as simple as adding "vmxnet" (on a single line) to the
file "/etc/initramfs-tools/modules" and rebuild your initrd (using: sudo
update-initramfs -u). Followed by a reboot ofcourse.
This is what I recall from what I did (I had same other projects take up
my time in the mean
I have another works-for-me (tm) solution (other than adding vmxnet to
initrd):
Modify /etc/init.d/open-vm-tools:
--- /etc/init.d/open-vm-tools.orig 2009-01-19 10:57:02.0 +0100
+++ /etc/init.d/open-vm-tools 2009-01-19 10:51:49.0 +0100
@@ -67,6 +67,7 @@
then
Public bug reported:
Binary package hint: installation-report
Example:
# ls /var/log/installer/initial-status.gz -l
-rw-r--r-- 1 root root 0 2009-03-02 12:02 /var/log/installer/initial-status.gz
I get similar results on Hardy and Intrepid, i386 and amd64.
** Affects: installation-report (Ubunt
Public bug reported:
Binary package hint: ipvsadm
As /sbin/ipvsadm is a wrapper script for 2 versions of ipvsadm and isn't
using full paths to those executables, running /sbin/ipvsadm when /sbin
is not part of $PATH, the script will fail. (Root) Cronjobs by default
don't appear to have /sbin in t
Public bug reported:
After a clean install of Ubuntu Gutsy Gibbon on a Dell PowerEdge860, the
network configuration is more or less messed up.
During installation there's an eth0 and eth1 interface (two broadcom nics, tg3
driver), which are configured fine. Yet after first reboot the devices app
** Changed in: udev (Ubuntu)
Sourcepackagename: None => udev
--
network interfaces not properly configured
https://bugs.launchpad.net/bugs/149319
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-b
After some troubleshooting with help from soren and ivoks on IRC, we
found out that a restart of udev (sudo /etc/init.d/udev stop && sudo
/etc/init.d/udev start) in fact does populate the file
/etc/udev/rules.d/70-persistent-net.rules properly.
Also in order to have the file properly generated whe
Public bug reported:
Binary package hint: udev
I have /var/log as a separate partition on top of lvm on top software raid. At
the time udev starts, /var/log isn't available yet. This causes the problem
that it can't move the logfile to /var/log/udev.log.
Furthermore, /var/log/boot shows "(Nothi
Some more information that might be related to this issue: /var/log
resides on a separate partition (lvm volume on software raid) which
causes some errors during boot. It complains about a command similar to
'mv /dev/.udev.log /var/log/udev.log'. This fails because /var/log isn't
available at that
*** This bug is a duplicate of bug 149319 ***
https://bugs.launchpad.net/bugs/149319
I had a hunch it would be related; I created this extra bug just to be
sure in case there wouldn't be an unilateral fix. Good job on the quick
fix!
--
Having /var/log as a seperate partition breaks udev and
Public bug reported:
10:50 < _ruben> another annoying thing btw (havent checked if there's a bug for
it already) .. say you create a /dev/md0 for /boot and a /dev/md1 for lvm ..
format /dev/md0 as ext2 and assign to /boot .. then go setup your lvm .. the
reference to /boot will be gone afterwar
Mohamed,
The current workaround is to use "sudo apt-get install lamp-server^"
instead of using tasksel. It also *seems* to be safe to just kill the
processes that tasksel has hanging around, since when doing so
everything *looks* being installed just ok. I ran a "sudo apt-get
install lamp-server^"
Same issue here. Installing "any" task (tried SSH/LAMP/Samba) causes
tasksel to hang at 100%. I don't recall the details but it involves a
process ending up in the Zombie state. Killing procs works, but is a
nasty workaround.
This is on a fresh-feisty-with-all-updates-upgraded-to-gutsy. As in: I
d
Excerpt from "ps uaxfww" :
ruben 4576 0.0 0.1 20692 3640 pts/0Ss 20:13 0:00 | \_
-bash
root 4796 0.1 0.4 36460 12568 pts/0S+ 20:13 0:00 |
\_ /usr/bin/perl /usr/bin/tasksel
root 4816 0.0 0.3 47924 10772 pts/0S+ 20:13 0:00 |
On Thursday 15 October 2009 at 19:06 (CET), Chuck Short wrote:
> 1. Is this reproducible?
Yes.
> 2. If so, what specific steps should we take to recreate this bug? Be as
> detailed as possible. This will help us to find and resolve the problem.
As described in the bugreport itself:
$ sudo cront
Public bug reported:
The currently shipped systemd unit file causes varnishlog to exit when
SIGHUP is sent to it.
SIGHUP has two meanings for varnishlog:
1) when running in daemon mode: reopen logfile
2) when not running in daemon mode: exit
Since the current systemd unit file doesn't run varn
What would it take to get this update going?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1547702
Title:
iputils-ping does not support IPv6 in ping command
To manage notifications about this bug g
This decision has some REALLY annoying side effects on Trusty, which
took us quite some time to figure out.
With the commented reload stanza, the reload function is broken in a
horrible way:
It sends SIGHUP to the php5-fpm master process causing it to terminate!
Without any warning or indication
I can confirm that removing libapache2-mod-perl2 "fixes" this. Question
remains: why does libapache2-mod-perl2 break it in the first place?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1008385
Title:
Patch appears to work for me as well. Any plans to release an update
yet?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/985198
Title:
Ldirectord "Subroutine main::pack_sockaddr_in6 redefined "
To
Public bug reported:
Fresh install of Ubuntu Server 12.04. 2 mdadm volumes, one for /boot and
one for LVM for the rest of the system. At each boot this error shows
up:
The disk drive for /boot is not yet ready or not present
If I choose manual recovery, I can do "mount /boot && exit" and the
boo
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1020914
Title:
The disk drive for /boot is not yet ready or not present
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/
Here's my revised patch. As there was still some stuff not working
properly.
** Attachment added: "fix-gethostinfo-v2"
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/985198/+attachment/3432065/+files/fix-gethostinfo-v2
--
You received this bug notification because you are a m
Really curious as to what could be used as a fix or workaround.
Currently it's "breaking" the New Relic agent on quite a few of our
servers (it fails to detect the Apache2 processes properly).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
Just did an interesting find:
When starting Apache using the usual "apache2ctl start", the process name is
mangled.
When starting Apache using the not-so-usual ". /etc/apache2/envvars && apache2
-k start", the process name isn't mangled.
Investigation continues...
--
You received this bug not
Turns out apache2 doesn't strip off the path properly:
"/usr/sbin/apache2 -k start" yields "/usr/sbin/apach"
"apache2 -k start" yields "apache2"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1008385
T
Unfortunately this isn't part of the actual solution. On "good" servers,
invoking it through /usr/sbin/apache2 works fine as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1008385
Title:
apache
29 matches
Mail list logo
