To test our robot software against the newest and shiniest compilers and
libs we have a rawhide VM. Today I noticed a very annoying problem
(after not using the VM for a while), but I'm not sure if it's on our
side or if I should file a bug.
The VM is frequently unable to access its root partition (using virtio
for this VM). SSH connection end with "broken pipe", if locally on the
machine trying to execute "dmesg" it only says "cannot find /bin/dmesg".
In the time when the error appears until I loose the connection was once
able to do "cat /proc/kmsg" showing errors on /dev/vda. In the libvirt
log on the host (CentOS 6.2 using libvirtd and virt-manager) I see the
following entries popping up in these situations:
block I/O error in device 'drive-virtio-disk0': Permission denied (13)
SELinux' audit.log is quiet. And the VM runs, and sometimes I can work
on it for 30mins straight, sometimes not even for 30secs. Any idea what
might be causing this intermittent problem?
During investigation I noticed that the very same message appears every
now and then in other VM's logs as well. They are running CentOS 6.2,
and one is FreeBSD 9.0. But in those I do not see the broken connection
or "cannot find file" problems.
The VM's disks are logical volumes in the same volume group. The machine
is a Dual Xeon Quad-Core with a speedy RAID array hosting the VG.
Does someone have a similar problem, or can give ideas how to fix or
investigate, and if to file a bug, which component to target? I'm not
even sure if it's a CentOS or a rawhide thing, though I assume the latter...
Regards from Aachen,
Tim Niemueller <tim(a)niemueller.de> www.niemueller.de
Imagination is more important than knowledge. (Albert Einstein)
Does setting emails in your inbox folder to junk working automatically?
It seem it doesn't do it automatically and I have to keep selecting them
and manually marking them junk.
On a fresh install (such as this one), I do a restore from a backup file
as I always do, to include doiong the same thing in F16 (that worked
just fine) and the settings are there, and set as suppose to be. Also
evolution-bogofilter is installed as well. Just for some reason it's
not setting them to junk automatically.
"Best little town on Earth!"
# Fedora Quality Assurance Meeting
# Date: 2012-04-02
# Time: 15:00 UTC
# Location: #fedora-meeting on irc.freenode.net
It's meeting time once more. As Beta slipped, we're still working on
blockers, so we'll be doing some review and RC3 planning. Also, we
didn't get to the 'QA as a sub-project' topic last week, so let's sign
off on it this week.
This is a reminder of the upcoming QA meeting. Please add any topic
suggestions to the meeting wiki page:
The current proposed agenda is included below.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 17 Beta status / blocker review
3. 'Project' status
4. Test Day report
5. Upcoming QA events
6. AutoQA update
7. Open floor
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
dd if=/dev/zero ~56MB/s CPU < 10%
dd if=/dev/urandom ~12MB/s CPU 99%
haveged ~54MB/s CPU < 25%
The dd relative values are consistent with kernels in Fedora 16. However these tests were done with 3.3.0-1. The questions are:
Is the urandom performance expected?
What is the quality of pseudo-random data produced by urandom vs haveged?
If the qualities are similar, or haveged's is better, is there anything that can be done to improve urandom's performance? It really takes quite a bit longer to prepare a disk/volume for encryption.
This affects the following:
Whose owners are CCd and which I'll handle rebuilding unless the
owners would rather.
in your fear, seek only peace
in your fear, seek only love
My problem is about possible ways to form the version-release fields for
a git post-release.. My example involves a version like 1.1.0 and a git
release like 20120329git1234567
Reading , all examples of post-release updates are on the form
foo-1.1.0-1.20120328git1234567.fc16. Obviously, this is one way to do it.
However, when I try to read the link carefully, I also see a possibility
to use a version-release like foo-184.108.40.20620328git1234567-1.fc16. My
reasoning based on the link:
- Version tags are either properly ordered or not.
- git tags like this are properly ordered (thanks to the date prefix).
- For properly ordered tags, the text explicitly says the tag can go
into the version field. However, there are no such examples.
Of course, another question is why. In short, I see some minor
advantages w r t robustness and consistency using this form. But for
now, this is not really the focus of this question.
So, my question: Reading , is a version-release like