How about using the fix suggested by in Debian Bug # 645880
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645880) ?
Simply start rpcbind without the '-w' option if neither of the relevant xdr
files exist.
I've modified the patch from the above Debian bug for compatibility with
Upstart:
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This may be related to bug #543064 (ensure that x-www-browser is used if
no http handler is found through gnome integration). Unfortunately,
that bug has been deferred until Ubuntu 10.10.
The additional issue with regard to missing dictionary files w
Hello Scott,
The updated mountall package (2.13~ppa1) appears to create more problems
than it solves.
Although the mountall process no longer spams the console with
"mountall: Plymouth command failed", there is now a more serious
problem. The system no longer boots, even if fsck isn't doing disk
This also affects me. I have the thunderbird-locale-en-gb and myspell-
en-gb packages installed. Thunderbird shows the language pack correctly
installed under 'Tools > Add-ons > Languages'. However, I am only able
to select the United States English dictionary when composing email.
Current pack
The problem still exists for me. However, in my case, no plymouth
processes were present after booting, even though mountall failed to
terminate (see comment 23 above). The only difference I have observed
is that KDM is running on a different console.
Booting the 2.6.32-20 kernel with 'nosplash'
There is also a possible additional duplicate of this, as bug #559761.
In that case, the mountall process remains after boot, using 100% CPU
time. However, there are no plymouth processes running at the time. I
have attached a backtrace of the mountall process to comment 8 of that
bug.
--
ply_b
> possible duplicate of 554079 ?
This bug is similar to (at least) 554079, 554737 and 557161. However,
there are differences in each case:
In bug #554079, it appears that plymouth is stalling during fsck, which
results in GDM not loading. 554079 also makes no mention of the
"mountall: Plymouth
I have a potential duplicate report of this bug as # 559761. In my
case, the "mountall: Plymouth command failed" message still loops on the
console. However, the mountall process fails to terminate properly, and
continues to use 100% CPU time after I've logged on.
Dennis, is it possible for you
A time-out issue may be causing this. My disk has a mixture of ext3 and
ext4 partitions, with one of the ext3 partitions at 91% capacity. This
causes fsck to take a long time. Below is the relevant portion of '$ df
-h'. I'm also attaching a copy of my '/etc/fstab', in case this helps
in resolvi
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/43625768/Dependencies.txt
** Attachment added: "ProcMaps.txt"
http://launchpadlibrarian.net/43625769/ProcMaps.txt
** Attachment added: "ProcStatus.txt"
http://launchpadlibrarian.net/43625770/ProcStatus.txt
--
mounta
Public bug reported:
Binary package hint: mountall
On boots when fsck runs, mountall appears to hang. The mountall process
consumes 100% CPU time, and the following error message loops on the console:
"mountall: Plymouth command failed"
Although this error message continues to loop on the main
>From my understanding, SELinux uses /selinux/ as a mount point for a
selinuxfs filesystem describing the current SELinux policy. AppArmor
uses a similar setup, with /sys/kernel/security/ used as a mount point
for the active AppArmor security policy.
A more appropriate mount point for the selinux
** Attachment added: "dpkg_-L_libselinux1.txt"
http://launchpadlibrarian.net/24561600/dpkg_-L_libselinux1.txt
--
/selinux/ directory created in root
https://bugs.launchpad.net/bugs/352193
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
Public bug reported:
Following a fresh install from kubuntu-9.04-beta-desktop-i386.iso, I
noticed that an empty directory /selinux/ has been created in the root
directory. The directory is owned by root, with permissions 755, and
appears to belong to the libselinux1 package. The presence of
addi
Adding the line:
capability dac_read_search,
to the cups-pdf section of /etc/apparmor.d/usr.sbin.cupsd allows cups-pdf to
function as expected in cases where ~/PDF/ exists with permissions 700, and
$HOME also has 700 permissions.
This is unusual, as AppArmor should not be interfering with the
The problem seems to be occurring in the prepareuser function of
/usr/lib/cups/backend/cups-pdf. Specifically, the following check fails to
correctly identify the presence of the user output directory (line 338 of
cups-pdf.c):
if (stat(dirname, &fstatus) || !S_ISDIR(fstatus.ts_mode))
Using
16 matches
Mail list logo
