I have made available a deltaiso from the i386 Preview DVD ISO to the
i386 RC2 ISO. It is 233945224 bytes (about 6-7% the size of the full
ISO) with MD5 f0413ba9d23be4dd1778a06f35c80a43, and can be downloaded from
(after clicking on the "Proceed to File Download Page" link). To apply
it, one needs to have the deltarpm package installed, and then run the
(assuming the first two files are in the current directory). On a
reasonably fast machine this should complete in about 15-20 minutes. Of
course, one should check the sha256sum of the final ISO (listed in
07f1229ad5717d63d2e08d556b9221be71a825ad83b9090b4632bf7208189bf6) - I
only provided the MD5 of the diso to allow a quick check that the
download isn't corrupted. I don't intend to make disos for the other
ISOs, since it would be far easier for someone who doesn't have to
download the full ISO first. This was just done as a demonstration.
Since the Preview for each of the platforms is already available on
numerous mirrors, I suggest that the RC server should only host disos,
with the Preview first being downloaded from elsewhere.
On a multi-disk system, start with at least the first disk (sda)
uninitialized and at least one of the others initialized (e.g., sdb,
partitioned or not). Install with any partitioning you desire. When
you get to the "install boot loader" screen, anaconda wants to install
grub on the first previously initialized disk (sdb in this example), not
on the actual first disk (sda).
There are two workarounds.
1. Click "Change Device" and tell anaconda to recognize a different
(i.e., the correct) BIOS order
2. After installation, boot into the DVD rescue mode to reinstall grub
and (very important!) to edit grub.conf for the correct hd numbers
Big deal or not? My take is it's a bug worth fixing at some point. For
F11 GA, it's probably enough to include it in the Release Notes as a
known issue (but still fix it for real later).
I've filed BZ #503299, but I thought I'd point it out for consideration
in the Release Notes if somebody thinks it's worth it.
I know that this has been a running problem for a while now, so I have not
chimed in. I am still concerned about it as it is still happening...
Does anybody have a clue as to why???
Rob G. Healey
--- On Tue, 5/19/09, Adam Williamson <awilliam(a)redhat.com> wrote:
> From: Adam Williamson <awilliam(a)redhat.com>
> Subject: Re: every so often, screen just goes black
> To: "For testers of Fedora Core development releases" <fedora-test-list(a)redhat.com>
> Date: Tuesday, May 19, 2009, 5:07 PM
> On Tue, 2009-05-19 at 23:24 +0000,
> "Jóhann B. Guðmundsson" wrote:
> > On 05/19/2009 09:44 PM, Robert P. J. Day wrote:
> > > for the display, mine's set for
> 30 minutes but it's *absolutely* not
> > > a function of that time value since, as others
> have mentioned, the
> > > screen can go black totally arbitrarily, like
> when i'm literally in
> > > the middle of typing something. can i
> assume that's pretty much
> > > what's happening to some of the others who have
> confirmed this?
> > >
> > Yup
> > 30 minutes here same symptom
> Can you guys set it to 'never' and see if the behaviour
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT
It happens! I see it in both GNOME and KDE environments. I had it to never and it happens as soon as I type something in internet. Moving the mouse or a touching a key gets me back. It is strange but it does happen. I guess it is not a big deal, but others may have other opinions.
I tried to run pre upgrade today and got an error message that my /boot
partition was too small. The message that it could download the file
during installation if I had an ethernet connection.
Rather than go through the whole thing, I stopped it and began to google
and to bugzilla, if there is such a word.
The impression I am getting is that it will eventually fail if the /boot
partition is too small. My /boot partition is about 100 MB or so. I
removed all older kernels and left the minimum in there. However, more
googling indicated the image it will need is actually over 100 MB.
So, I am not sure if it would eventually fail or not if I try to go the
preupgrade route. This was from an F10 install, which probably had a
default /boot of 100, but I could be wrong about that, I'm not sure if I
manually did the partitioning or not.
If that is correct, I wonder if it would better to have a more emphatic
message--the message was a bit ambiguous to me, not really stating if it
would fail later, even if the image is downloaded, if the /boot
partition is too small.
I only gave it about 5 minutes on google, so stopped after the first few
hits, many of which were older, so I'm not sure if this is still the
case or not.
Thanks for any clarification.
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Willow: Oz is a werewolf.
Buffy: It's a long story.
Oz: Got bit.
Buffy: But obviously not that long.
Andre Robatino wrote in fedora-test-list:
> I have made available a deltaiso from the i386 Preview DVD ISO to the
> i386 RC2 ISO. It is 233945224 bytes (about 6-7% the size of the full
> ISO) with MD5 f0413ba9d23be4dd1778a06f35c80a43, and can be downloaded from
> ... To apply
> it, one needs to have the deltarpm package installed, and then run the
> applydeltaiso Fedora-11-Preview-i386-DVD.iso
> Fedora-11-Preview_rc2-i386-DVD.diso Fedora-11-i386-DVD.iso
> ... Of
> course, one should check the sha256sum of the final ISO (listed in
> Fedora-11-i386-CHECKSUM as
> ... This was just done as a demonstration. ...
Hmm... Make the technology work *for* you. A novel idea.
Maybe the GA could be distributed the same way, like to mirrors and end
users. It only works for places that already have the previous image
(i.e., Preview in this case), but that's at least the testers.
Compose started at Sat May 30 06:15:04 UTC 2009
Added Packages: 0
Removed Packages: 0
Modified Packages: 0
Broken deps for ppc64
cabal2spec-0.12-1.fc11.noarch requires ghc > 0:6.10.1-7
I'm having vncviewer problems with f11 that I don't think
I had with f10 with respect to receiving clipboard
data from a vncviewer session. I can paste into the
vncviewer session, but I can't copy from the vncviewer
session and paste into my f11 X session. The vncserver
it configured to send and receive clipboard. It's an fc6
vncserver session that I've tested it with and I believe I
was able to copy/paste both ways from the same vncserver
session from f10. Is this a bug, or do I need to do
something different from f10 to make this work?
I'm trying to get a Dell M1330 with Intel GM965 ,using HDMI interface,
connected to a Samsung TV (LA32B650). The connection works but I cannot get
any better resolution than 1024x768 and I have HDMI Audio option in
pulseaudio profiles, I have no sound. Has anyone got similar setup to work
at native 1920x1080 resolution with audio? Also, if it is a problem with not
detecting TV's modes, is there a way to manually set the resolution for a
This is on a up-to-date rawhide.
Doing a yum update just now. After
Package Openoffice.org-langpack-ja_JP.ppc 1:3.1.0-11.3.fc11 set to be
it spits out
Unicode unequal comparison failed to convert both arguments to
Unicode - interpreting them as being unequal
if reqn != n:
and then continues with
Package openoffice.org-math.ppc 1:3.1.0-11.3.fc11 set to be updated
Does this need to be reported somewhere or just ignored?