Re: Email problem, evolution asking for unknow password
by Vinny Onelli
> On Mon, Jun 6, 2011 at 1:15 AM, Vincent <vonelli(a)verizon.net> wrote:
> >> From: Pasha R <pashar.ml(a)gmail.com>
> >> On Sat, Jun 4, 2011 at 9:12 PM, Vincent <vonelli(a)verizon.net> wrote:
> >> > Hello,
> This feature (storing passwords in keyring) presents in several
> releases already, since F12 at least. Try to create default keyring
> without password using seahorse.
>
I apologize for my ignorance, just don't know how getting around.
I try but couldn't find the way to fix, so I decided to reinstall F15
for now it works OK, I also check the new installation with seahorse and
found to be exactly the same.
I would still like to understand the mechanism just in case that happens
again.
thank you very much.
Vinny
12 years, 11 months
Help needed. Lightining-Thunderbird on Fc14.x86_64.
by Lucélio Gomes de Freitas
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
Trying to Install Mozilla-Lightning on Fedora 2.6.35.13-91.fc14.x86_64
and got the message:
"lightning" could not be installed because it is not compatible with
your thunderbird build type (
linux_x86_64-*gcc3*). please contact the author of this item about the
problem.
I can't belive that they don't have a 64bit version?
Anybody has a workaround for this?
Thanks in advance,
- --
Lucélio Gomes de Freitas
ETFCSF-> U.G.F.-> P.U.C.(RJ)
Engº, Analista Suporte(Free Mind).
Email: aa.lucelio(a)gmail.com
Tel: 55 0XX 21 85964911
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iF4EAREIAAYFAk3tX+8ACgkQENqGaHfBA/ddjwD8C8Rot+GG3UO/o9bxSofMbwRV
7/XjKMh4rtC309ABdUgA/ieIITv/xig/0QFdRTTAuVFCaxnETqGs7cHrK6dVm8j2
=iyWn
-----END PGP SIGNATURE-----
12 years, 11 months
Preupgrade still sucks. Maybe sucks less, maybe sucks more.
by Michael H. Warfield
Ok...
The subject line may well get some unwanted attention and ignite a flame
war but just bare with me. This has not been a fun last couple of days
for me.
Understand one thing about me. I manage a number of remote servers to
which I had no console access other than serial consoles. I do have
remote power control over them. If I have to drive an hour out to a
colo facility to fix a broken install or upgrade, it's a very bad day.
Classically, for those servers (some of which originally started out on
FC1) have been upgraded using the yum upgrade method. There have been
one or two times when that has been challenging, thanks to odd
dependencies, but not many. I've gotten that down to a science where I
dump the current rpm table using "rpm -qa --qf '%{NAME}\n" | sort -u"
into a file and simply remove any conflicts until it upgrades and then
reinstall based on what's in that file. The work that has been done on
the yum upgrade page simplifying the process to the point where it's
just a "yum update ; yum clean all ; yum --releasever=??" is incredible.
It works so smoothly now compared to what you had to do years ago. And
the server stays up the entire time of the upgrade. I don't loose any
significant downtime with those machines.
But... Each click of Fedora, I do try and give preupgrade a shot and
see how bad it is or see if they've improved things. I do this on my
local workstations and I can see how much downtime is involved and if
there are any gotchas.
So it was this time. My intent was to take two of my 64 bit machines
and upgrade one, "Forest", using preupgrade and one, "MtKing" (both
names from the old game of Colossal Caverns Adventure) using yum upgrade
to compare the upgrade time, downtime and the resulting rpm sets. Both
machines had the same rpms installed and both machines were up to date.
I also use the pkgcacher package on one of my other servers so I'm only
downloading copies of packages once and both machines can suck them in
from that cache.
So... Forest ran preupgrade and downloaded all the packages and was
ready to reboot, which I did. MtKing downloaded all the packages and
ran into dependency problems, which isn't uncommon with the yum updated
path. So I decided, what the hell and ran preupgrade on it as well and
then rebooted it. With the package cacher, the downloads of something
like 2000-3000 packages took less that 5 minutes for each machine.
While it was down and grinding on its disk, Forest got an non-specific
unhandled exception and was stuck at the console requiring a manual
reboot. Well, that tells me right there that preupgrade is still not
deployment grade yet. Not for remote servers at least. That would have
cost me a trip to the colo if it had been remote. Not good. MtKing
also failed preupgrade but this was because it was short disk space in
one partition. That was easy to fix but, again, it's requiring console
interaction or it's dead. The yum upgrade also would have told me it
was short on diskspace for the install before getting this far down the
road and having the bloody server off line at the time, saving me a
couple of reboots and other jacking around.
So, I switch plans, knowing what the problem was on MtKing and having no
clue what caused anaconda to hurl chunks on Forest. I freed up some
space on MtKing and reran preupgrade while I ran yum upgrade on Forrest.
Forest had some dependency problems, like MtKing (to be expected - they
were the same), but this time I simply dumped the rpm table to a file,
like I always do, and started removing the bad boys. Couple of minor
things, really. Stick in the mud was avidmux which really had it tied
in a knot with some missing upgrade library but had no problem pulling
that and then yum upgrade is chugging away (still can't reinstall
avidmux because of that missing library). Half hour later, it's done
and the machine is rebooted and up, more or less. Then I found that
someone had screwed up IPv6 over bridges by forcing accept_ra = 0 and
forwarding = 1 in the bloody scripts. I'll deal with that with a bug
report later. Absolutely stupid. A bridge is not forwarding, it's
bridging and they go and break autoconf by this misguided step. But
that's another story. Shortly after sorting that out, I have Forest up
and the half dozen LXC virtual machines running on him and everything is
right with the world.
ITMT... I rebooted MtKing into the preupgrade process and turned it
loose. Strangely, it DIDN'T run into the unhandled exception like
Forest had. The machines should have been the same. Oh well.
Something like two HOURS later, though, and it's still grinding on the
disk. WTH? Why is preupgrade taking 4 times longer to upgrade a system
and that's with the system down and out of service during the entire
process. Well, it finally finished and I rebooted into the F15 kernel
and was almost immediately greeted with a kernel panic unable to mount
root fs on unknown block(0,0). Sigh... This would be real great at a
remote location. Ok, I'm screwed. Yum upgrade worked over on Forest
where preupgrade demonstrated an epic fail, and now MtKing has succumbed
to another failure. Tried booting into one of the F14 kernels that were
still on the system. You can forget that noise as well. I ended up at
the "Welcome to emergency mode. Use systemctl default or ^D to activate
the default mode". Grrr... Log in and tried that "systemctl
default"... No joy. "Failed to issue method call: Transaction is
destructive." Great. That's a delightfully spooky error that tells you
absolutely nothing. Looks like it burned my bridges on the way out the
door.
OTOH... My son, who is another skilled developer and Linux enthusiast,
has used preupgrade successfully on one of his 64 bit stations but he
also noticed that the upgrade took seemingly forever. Like hours. So
that's not just me.
Well, I've got a dead machine to try and recover from now. I've heard
all the arguments about how preupgrade should be so much better because
you're running anaconda on an install kernel. That has simply NOT been
my experience at all. On the contrary - exactly to the opposite.
Preupgrade fails to do the necessary disk space checking and dependency
checking that ultimately causes these failures, all of which could be
resolved remotely on a live running system without requiring repeated
reboots. I have no idea what anaconda is doing that is so broken that
it takes over 4 times longer to upgrade a system than yum, but the yum
upgrade path has worked flawlessly (not always effortlessly, but
flawlessly) for years. For now - preupgrade => epic fail * 2. If
anyone has any thoughts on what has caused either of the two remaining
problems (the kernel panic on the F15 kernel or the failure to run on
the F14 kernel) I'd be happy to hear them. ITMT, I guess I'll start
building a recovery CD to try and fix this mess.
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
12 years, 11 months
What is causing the unlocking of Widgets in and up to KDE-4.6
by Mickey
The Unlocking of Widgets and Screwing up the the whole Desktop and Panel
in and upto KDE-4.6, WHAT IS GOINGON !!!!
I have every day a new Linux User calling me up and saying My Panel or
Desktop is messed up again. telling them be sure the Widgets are Locked
, this is getting old, when I know I keep my own Widgets lock, but they
still keep getting unlocked.
And switching to Gnome desktop is Totally out of the question.
12 years, 11 months
What's with systemd?
by Arthur Dent
Hello all,
I have just upgraded my F13 machine to F15. This acts as a server,
providing mail and web etc. (only 3 users - it's for me and my family).
I have tried very hard to understand how systemd works but I'm just not
there yet.
I was OK with init scripts and chkconfig, but now when I try to start a
service I often get a cheery "OK" on the terminal, but in fact the
service has failed completely. Even if I get a "Failed" message I can't
find anywhere the reason why the startup failed. I have resorted to
starting the offending application by typing the name of the binary into
a terminal to see what messages it provides...
Anyway... Rant over...
The real problem I have is that after a reboot, several key services
fail to start. The crucial ones (for me) are sendmail and dovecot. There
are no messages in any logs (that I can find), but my mailchain just
isn't working.
I start them manually, and then all is well. I can't understand why
(especially sendmail) fails to start after a reboot.
Any ideas?
Thanks in advance...
Mark
# chkconfig dovecot --list
Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.
# chkconfig sendmail --list
Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
12 years, 11 months
Fedora 14: iPod not mounting
by Neil Bird
I just got an iPod Touch 4G for my son, and tried it in my Fedora 14 PC
(he has a school Windows laptop I can put iTunes on but I'd rather get it
working “properly” :) )
When I plug it in I get am error popup:
unable to mount ipod touch
dbus error org.freedesktop.dbus.error.noreply: message did not receive a
reply (timeout by message bus)
The only other indication is a new icon in the drivemount-applet (but
that then crashes when I choose “Mount iPod”!). I don't recall seeing
anything on the desktop (like when USB sticks or CDs are inserted).
I also don't see the thing creating a /dev device: my understanding was
that the iPod should still appear as a USB storage device.
Relevant messages:
Jun 3 06:26:03 xxx kernel: [323135.822095] usb 1-4.2: USB disconnect,
address 17
Jun 3 06:26:15 xxx kernel: [323147.915711] usb 2-2: new high speed USB
device using ehci_hcd and address 2
Jun 3 06:26:15 xxx kernel: [323148.034570] usb 2-2: New USB device found,
idVendor=05ac, idProduct=129e
Jun 3 06:26:15 xxx kernel: [323148.034573] usb 2-2: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
Jun 3 06:26:15 xxx kernel: [323148.034575] usb 2-2: Product: iPod
Jun 3 06:26:15 xxx kernel: [323148.034576] usb 2-2: Manufacturer: Apple Inc.
Jun 3 06:26:15 xxx kernel: [323148.034577] usb 2-2: SerialNumber: xxx
Jun 3 06:27:15 xxx kernel: [323207.561628] usb 2-2: USB disconnect, address 2
Any suggestions as to what to look at next?
I shall try to find the USB IDs in the h/w database/udev/hal/whatever
files to see if it's one that just needs to be added, but short of that I'm
at a loss.
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit
12 years, 11 months
Terminal in Gnome 3?? Main Menu???
by Beartooth
I have F15 with Gnome 3 running on a live CD in a laptop -- and
two things I can't so much as get a sniff of are gnome-terminal, and
whatever (if anything) corresponds to the Main Menu. Clue, please?
--
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.
12 years, 11 months
SELinux is preventing /usr/libexec/colord from getattr access on the file /usr/local/Brother/sane/models3/ext1.ini.
by Lawrence E Graves
This is what I got when using the command you given me. chcon command
SELinux is preventing /usr/libexec/colord from getattr access on the file /usr/local/Brother/sane/models3/ext1.ini.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that colord should be allowed getattr access on the ext1.ini file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep colord /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:colord_t:s0-s0:c0.c1023
Target Context system_u:object_r:bin_t:s0
Target Objects /usr/local/Brother/sane/models3/ext1.ini [ file ]
Source colord
Source Path /usr/libexec/colord
Port <Unknown>
Host JesusChrist.localdomain
Source RPM Packages colord-0.1.7-1.fc15
Target RPM Packages brscan3-0.2.11-4
Policy RPM selinux-policy-3.9.16-26.fc15
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name JesusChrist.localdomain
Platform Linux JesusChrist.localdomain
2.6.38.7-30.fc15.x86_64 #1 SMP Fri May 27 05:15:53
UTC 2011 x86_64 x86_64
Alert Count 2
First Seen Mon 06 Jun 2011 10:57:21 AM MDT
Last Seen Mon 06 Jun 2011 12:46:24 PM MDT
Local ID aadfaddf-1131-418c-af42-c46d79803ac2
Raw Audit Messages
type=AVC msg=audit(1307385984.492:28): avc: denied { getattr } for pid=1265 comm="colord" path="/usr/local/Brother/sane/models3/ext1.ini" dev=dm-1 ino=2774893 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file
type=SYSCALL msg=audit(1307385984.492:28): arch=x86_64 syscall=fstat success=yes exit=0 a0=12 a1=7fff576a9e30 a2=7fff576a9e30 a3=7fff576a9d20 items=0 ppid=1 pid=1265 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=colord exe=/usr/libexec/colord subj=system_u:system_r:colord_t:s0-s0:c0.c1023 key=(null)
Hash: colord,colord_t,bin_t,file,getattr
audit2allow
#============= colord_t ==============
allow colord_t bin_t:file getattr;
audit2allow -R
#============= colord_t ==============
allow colord_t bin_t:file getattr;
--
Lawrence E Graves <lgraves(a)risingstarmbc.com>
12 years, 11 months
LibreOffice and Evolution will not print
by Lawrence E Graves
I am still laboring over the fact that LibreOffice and Evolution and
gedit will not allow me to print. If it was just one of them I would not
be as concern because I believe it would be fixed eventually. When
important places of use are not performing that's a problem. Still
patiently waiting for a answer or better a solution.
--
Lawrence E Graves <lgraves(a)risingstarmbc.com>
All things are workable but not all things work.
Prov. 3:5&6
12 years, 11 months
Re: Preupgrade F14-->F15 [Solved]
by Elliott Chapin
-----Original message-----
From: Benjamin benjamin10(a)gmx.at
Date: Mon, 06 Jun 2011 10:27:41 -0400
To: echapin echapin(a)teksavvy.com, Community support for Fedora users users(a)lists.fedoraproject.org
Subject: Re: Preupgrade F14-->F15 [Solved]
> Am 06.06.2011 15:20, schrieb echapin:
> > -----Original message-----
> > From: Benjamin benjamin10(a)gmx.at
> > Date: Mon, 06 Jun 2011 08:17:58 -0400
> > To: Community support for Fedora users users(a)lists.fedoraproject.org
> > Subject: Preupgrade F14-->F15
> >
> >> Hello everyone!
> >> I encountered the following problem when trying to upgrade my system:
> >>
> >> After preupgrade has downloaded all the packages and the system has
> >> shutdown to establish the new system, while the installation process
> >> there came the failure:
> >> Too less space on / (or something similar)
> >>
> >> So i guess that my /boot partition is too small to perform the
> >> preupgrade, which is a problem a can´t solve alone. I need your help.
> >>
> >> Thx. Benjamin.
> > Try a wired connection if you haven't already, and ignore warnings.
> >
> >
> Thanks a lot echapin! That helped. Beside: Why did this help?
I don't know. This notion has been around for a version or two, and I don't remember the technicalities. Maybe someone else can fill them in. In any case I'm waiting 'til the general complaint level has died down a bit more and some packages I use catch up.
>
12 years, 11 months