This is still and issue, 2 years on. If you install nodejs, it will
install javascript-common and break every site on the server.
Marvellous.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/711196
** Description changed:
Summarising from
https://answers.launchpad.net/ubuntu/+source/novnc/+question/271057
utils/launch.sh (present in the novnc source package) is a fairly
essential part of this application. Without it a user really needs to
know how to start up websockify
This is a file, in the format to place it in debian/patches in the
source tree
** Patch added: "Patch to fix utils/launch.sh"
https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/1492351/+attachment/4458677/+files/utils-launch.patch
--
You received this bug notification because you are a
This patches the debian folder in the source package, to alter the dpkg-
buildpackage and install scripts, to ensure the new launch.sh patch (see
earlier patch) is run, and that utils/launch.sh is included in the novnc
package.
The original debian/rules file, wiped the whole novnc/utils folder
Public bug reported:
Summarising from
https://answers.launchpad.net/ubuntu/+source/novnc/+question/271057
utils/launch.sh (present in the novnc source package) is a fairly
essential part of this application. Without it a user really needs to
know how to start up websockify manually, and all the
Public bug reported:
not sure what I can add to be helpful, I ran do-release-upgrade to
upgrade an old machine from 12.04 to 14.04 and it first told me it would
disable all 3rd party add-ons (and prompts to recover or close the
window)
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package:
boot_required is simply deduced by interrogating fstab, to find mount
points which are 'required' to boot, (ie have a pass value not 0).
The script logs anything (and all) of the strings which it thinks might
enable it to identify at boot time, a device which might be subsequently
required.
Ok, think I've fixed this. I've changed the /usr/share/initramfs-
tools/hooks/mdadm function, so that as well as putting mdadm.conf in the
/etc/mdadm folder when generating an initramfs, it also generates a
/etc/mdadm/boot_required file, which is a list of devices and UUID which
the hook deduced
diff -u -r initramfs-tools/hooks/mdadm initramfs-tools-mdadm-changes/hooks/mdadm
--- initramfs-tools/hooks/mdadm 2012-08-04 07:54:25.0 +0100
+++ initramfs-tools-mdadm-changes/hooks/mdadm 2012-10-03 16:24:49.0
+0100
@@ -61,12 +61,112 @@
done
# copy the mdadm configuration
A quick hint, to those that didn't know (like me) at the (initramfs)
prompt, if the failed raid array isn't needed to boot, then you can
simply type return 0 to have it continue normally with the boot
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I have a similar problem, but suspect the issue I'm having means it must
be either down to code in the kernel or options unique to my
ubuntu/kernel config. /proc/version reports: 3.2.0-30-generic.
In my case, I have 5 disks in my system, 4 are on a backplane,
connected directly to the
I submitted this in reference to 990913 but now think that relates to
the mdadm/udev racing condition discussed in 917250. My issue is that
a attached, degraded, devices which should not be required, are
preventing my setup from booting:-
I have a similar problem, but suspect the issue I'm
I thought it helpful to link to
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/917250 which seems
related, although pertains specifically to racing conditions leading to
disks being erroneously degraded rather than legitimately degraded, but
irrelevant disk causing inappropriate boot
I thought it helpful to link to
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/872220 which seems
related, although pertains specifically to inappropriate boot failures
due to irrelevant disks being degraded rather than racing conditions
coming from disks being erroneously degraded.
It's
sorry bad link, try
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/990913
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/872220
Title:
Fails to boot when there's problems with softraid
To
I've not tried this on a newer version of ubuntu, as I only tend to use
LTS versions. I haven't got my head around the new post sys V startup
thing, but the issue was that it needs to start after networking, but
was trying to start before it.
I would assume from what you're saying, that in
Sorry Hadn't realised this was purely karmic. I identified the problem
on lucid and on maverik. I've never used karmic, but I have had this
problem. Is there an easy way to transfer it over to a different
version of ubuntu?
--
You received this bug notification because you are a member of
Hi Andres,
Sorry Hadn't realised the bug, was just about karmic. I've only used
lucid/maverik, and have encountered it a few times. Could the bug be
re-identified as lucid or my comments be transfered to a new bug?
Simon
On 24/06/11 16:11, Andres Rodriguez wrote:
Thank you for taking the
I'd be surprised if passenger would allow itself to run as root.
Anecdotal evidence suggests it isn't as on my setup, before I added the
PassengerDefaultUser record to passenger.conf my setup was complaining
that it didn't have write access to /etc/redmine/default/session.yml,
which was owned by
(I'd guess that it passenger becomes nobody if it finds that it is root).
So either way a fix is needed, either:-
1) Add PassengerDefaultUser www-data to passenger.conf
or
2) Add code to the package script, to set the ownership of environment.rb to
www-data
#1 would seem to me to be the best
I think the actual bug is misidentified here, even if the effect is the
same:-
If you install gmetad on a virgin machine, it creates
/var/lib/ganglia/rrds owned by nobody.
If you install ganglia-monitor on a virgin machine it creates
/var/lib/ganglia/rrds owned by ganglia
If you install gmetad
The bug appears to be in the ganglia.diff.gz file in the package source.
It includes code which creates a debian folder, within which is create a
file ganglia-monitor.postinst
That file includes code which will create the directory
/var/lib/ganglia/rrds and then run chown -R ganglia:ganglia
This is fixed in maverick, by changing the above bit of package code to
remove the references to rrds and the -R to leave rrds alone. :-
3337 +if [ -d /var/lib/ganglia ]; then
3338 + chown ganglia:ganglia /var/lib/ganglia
3339 + chmod 0755 /var/lib/ganglia
3340 +fi
Can I suggest as an update,
The folder /etc/defaults/ contains many such files, and is there
essentially to add config settings which apply to the startup script for
a particular service.
By default haproxy doesn't do anything useful, in fact it's worst than
that, it's a massive security hole, which would block up several
Perhaps you would be better off adding a feature request, for a dpkg-
reconfigure style step by step config process for a basic setup.
Without knowing the IP address of your servers, the package could never
know what you would need as a basic setup.
--
You received this bug notification because
Just a quick follow up, that didn't fix it. It went away for a bit,
then magically came back. The solution seemed to be to add networking
to init.d startup directories before haproxy:-
update-rc.d networking start 35 2 3 4 5 .
Like I said, the solution is probably to create a proper upstart
Public bug reported:
Binary package hint: haproxy
I've got haproxy installed and configured on one of my servers. In the
first 'listen' section of the config file, it binds to a number of
aliased IP addresses. While I can start the service fine from the login
prompt, it would not start at boot
27 matches
Mail list logo
