FC2-test2-i386-DVD.iso was 4306010112 bytes, which is a multiple of
32KiB (specifically, 4306010112 bytes = 131409 32KiB-sized blocks).
However, FC2-test3-i386-DVD.iso is 4379752448 bytes, which is *not* a
multiple of 32KiB:
$ factor 4379752448
4379752448: 2 2 2 2 2 2 2 2 2 2 2 2138551
Therefore, growisofs pads it by 18432 bytes up to 4379770880 bytes
(133660 32KiB-sized blocks) when burning it. This makes it a pain to
verify the MD5 checksums; instead of being able to just run md5sum on
the device (e.g., "md5sum /dev/hdc"), you have to use dd to read only
the size of the ISO (without the pad).
Was FC2-test3-i386-DVD.iso not being a multiple of 32KiB blocks in
size intentional, or just an oversight? And will the DVD ISO for FC2
final be a multiple of 32KiB blocks in length?
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
I am downloading the test 3 isos now and experienced a system slowdown.
I got errors to dmesg that were repetative and slowed down the system a lot.
The computer was not locked up, but slow as <enter very slow item here>
The bug that I filed was the below.
I could not find one similar. So I filed new. Is this a duplicate? Bug #?
swapper: page allocation failure. order:1, mode:0x20
[<228f00fd>] ei_receive+0x157/0x26c 
[<228f027e>] ei_rx_overrun+0x6c/0x8e 
[<228efc14>] ei_interrupt+0x1c0/0x323 
... some context snipped for brevity...
>> If yum is supposed to replace up2date, then its config file, should be a
>> of up2date.
>Who said yum is supposed to replace up2date?
If yum is not to replace up2date for updating, then why does it exist?
What itch is _it_ scratching that up2date
Or is it another case of 'Not Invented Here' syndrome?
>> After all, they are both supposed to do the same thing.
>Again, KDE vs. Gnome, vi vs. emacs, etc.
but KDE and Gnome do _not_ do the same thing, and they do not
use the same config files, and they are not infered to work together
(except for the rhn applet that does work on both task bars.)
As for vi vrs emacs, they both operate on the same kind text files,
and when your done editing your file with one, the file is still readable
and usable by the other editor, so thats not a valid analogy.
>> The bigger issues is that headers are saved in two different directories
>> on your system, so its guaranteed to get out of sync.
>Huh? Neither needs the others headers.
Its more like neither _uses_ the other's headers...
hence the duplication and inconsistency problems that result.
(see the final comment).
>> c) If you decide to carry on with up2date, you now have to ignore all
>> of the GPG errors, because of... (well I don't know).
>Of install the correct GPG keys...
What are the correct keys?
I installed test 3 from the release CDs and went through the
upgrade process. Are there other manual, un-documented steps
that need to be performed to get rid of these GPG errors?
If so, please give me a link.
>> e) Ohh, sometimes up2date hangs... Well just re-install, maybe it'll
>Have a reproducible situation? A bug number? I've been using up2date on
>FC1, FC2Test2, and FC2Test3 and I don't recall any hangs.
Yes, 100% reproducible since yesterdays's daily RPM fetch.
... while typing this message, I tried it again, and it no longer
hangs. :-( Maybe some of my earlier playing with the header
directories has resolved something... I don't know....
But the 'there are 2 packages to fetch, but you can only select
one of them' issue still remains.
>> d) If you get frustrated by the now broken up2date and the GPG issues
>> you resort to using yum. But sometimes _it_ lies.
>So if "you resort to using yum" why do you think it should replace
Because I don't know which tool I _should_ be using. :-(
I'd like to use the rhn_applet and up2date because:
a) thats what I used with RH7.x, 8.x, 9.x
b) it always _used_ to work
c) its on the desktop and its pretty,
d) and most of the time it works (or at least it did,
ignoring the 'size reporting' issue and the "GPG error' issues.
But now that doesn't work so I have to use yum,
which gets me a 'little' further.
>> So in the end you don't know what you've got,
>> who's wrong, whats wrong
>> or where and how to fix it.
>They all use the same rpm database.
Sorry, I was talking about the various update notice facilities
and updating processes, not their end product.
>> I don't mind having choices, but at least one of those choices should
>> work, and if the others don't. Then they shouldn't be supplied.
>Both work for me. YMMV.
And both used to work for me too. Its just that as the days
go by, and as we moved from test2 to test3, things are
... snip ...
>I'm sorry, if you are not interested in new features why are you running a
Because I want some of those new feature, but call me selfish...
I also don't want some of the old features broken. ;-)
Like up2date, or USB hotplug.
>>So set up multiple rsync jobs and have a human check that the first is
>> No, set up one job that rsyncs the RPMs, and then rsyncs the headers.
>And the case of headers being release on the main site after the first job
>is started is resolved how?
If there is a dependency and synchronization requirement on the
updating facility, then rsync is 'inappropriate' to use to maintain
mirrors in order to ensure 'system integrity'.
>>>Yes, I think you should pick one and throw the rest away.
>> OK, which one? Which one works? ...Neither.
>In my experience both.
That _used_ to be my experience, but since the virgin install of
test3, this no longer seems to be the case (and its not just me,
count at least 2 occurances here in Canada).
> If you are trying to run up2date and yum at the same time you might have
> just answered your own question.
Then I'm back to asking which one _should_ I be using?
>> But neither of them use the same front end database and neither
>> seem to work right... anymore.
>Both use a yum repo and both put transactions into the RPM database. What
>database are you talking about?
The directories where current and ancient headers and rpms are saved:
I noted that in the 3.x series of procps, the --format option no longer
supports the listing of the cpu in "ps"
Is there another way I can do this without using "top?"
Metro One Telecommunications
I finally got around to downloading test 3 and have attempted to install
it for the last couple of hours but haven't had any luck so far. I am
running into an issue where it is hanging right after the message
"Uncompressing Linux... ok, booting the kernel". From there on out the
cursor just flashes on the left side of the screen and my system is hung,
it requires a hard reset to reboot.
I have searched this list and google for suggestions but haven't had any
luck so far. I tried CD1 in another machine to rule out a bad CD (the
MD5SUMS matched before I burnt them) and the CD appears fine. I am sure it
has something to do with my hardware but I thought I would at least post a
message to see if people with similiar hardware have had some luck.
My configuration is as follows:
ASUS P4P800 Motherboard
P4 2.6GHz (HyperThreading Enabled)
512 MB PC2700 RAM
120 GB SATA drive (set as first drive)
40 GB ATA/100 (PATA)
Plextor 8/4/32 CDRW (master on secondary)
Pioneer DVD ROM (slave)
I have tried different variations such as disabling SATA support,
HyperThreading, "Compatible Mode", and even flashed the BIOS to a more
recent version for S&G... Anyway, thanks in advance.
Scanned by ClamAv - http://www.clamav.net
Intel says that a cpu with HT turned on is faster, but is that true for
Linux? and for FC2 as well?, I have seen some @intel.com posts so a
Intel Inside view could be very interesing.
some people of the list are also kernel developers... so a kernel
developer view also can be helpful...
In this link are some benchmarks that don't show any real improvement on
a HT-on cpu vs a HT-off CPU.
(not my page... just a google result looking for hypertread linux
Is that True?
Some links to other HT benchmarks on Linux can be helpfull...
Christian B. Ellsworth Capo (k(a)dicec.cl)
Linux Chief Engineer
RedHat Certified Engineer (RHCE)
Mariano Sanchez Fontecillas 966b, Las Condes, Santiago, Chile.
Phone (56 2) 2633340
Fax (56 2) 2071820
Mobile (56 9) 4195632
All Your Base Are Belong To Tux
I'm trying to file a bug against OpenOffice 1.1.1-4, but the only entry in
BugBuddy is for OpenOffice Ximian. Is that where I should file it ?
Also, i checked if the bug exists in the OpenOffice buglist but couldn't
find it. Is there a list on Fedora that I should check as well ?
Opera M2 Mail Client on FedoraCore2_Test3
I've just brought up a dual Opteron machine with FC2T3. This is my
first FC2 install, and everything seems to be going well except for
Automounting is used extensively here for home directories and for
third-party apps in /usr/local. For often used applications we rsync
some directories from a central server. (One day I'll make RPMs out
of everything, but for now this is much easier.) So
/etc/auto_usr_local has lines like:
This has worked fine for years now, from FC1 on back, with bind mounts
being used for the dirctories on localhost. Under FC2T3, however,
/usr/local/mathematica is there while /usr/local/matlab is not. This
appears in the logs:
Apr 29 12:52:28 compute08 automount: failed to mount /usr/local/matlab
I guess the move to autofs4 is involved but I don't know if what I'm
doing is expected not to work or if this is a real bug.