don't know if this will get me "banned" from the fedora-ppc list, but I
did an install of (K)Ubuntu today and it was the easiest linux
installation I've ever done: download one (1) iso image, burn it do
disc, boot off of it, type "install", accept the prompts (for the most
part), and within 20 minutes I had a dual-boot configured and running on
Hi. I've got an ISO for quick testing of anaconda's X configuration
setup available that's a little bit smaller than a full tree. All you
should have to do is download the ISO, burn it to a CD, boot and see if
X starts up. Then, you can reboot and go back to your normal doings.
Note that this is entirely non-destructive. So you can even run it if
you are running OS X. *ANY* results would be helpful. Please be sure
to include what you see happen as well as what type of hardware you're
using (cpu, video, monitor).
The iso is located at http://people.redhat.com/~katzj/mac-x-test.iso.
The md5sum is 34234b3cdf2d89e4e94031a50f819285
Thanks in advance for testing this and helping to make test3 (and thus,
the Fedora Core 4 release) better on PPC hardware!
I've just started trying to install fc3 on my old PowerCenterPro. I've
got the installer starting using BootX, but then I get to a similar
problem as was reported here back in november:
>but at the PowerMacG3 -- which should work with the bmac driver -- there I
>don't i cannot get the network connection to work even when i mannually
>select the driver. The automatic detection doesn't work at all.
>>/ > but with the bmac driver. alt Alt+F4 it says:
>/>/ > <7> divert: allocating divert_blk for eth0
>/>/ > <6> eth0: BMAC+ at 00:05:02:61:a3:51
>/>/ > so i guess anaconda could load the driver. but it doesn't go further
>/>/ > then. It just keeps me asking to select a driver...
>/>/ Ah ok this is a bug, I've not been able to track down yet.
My problem is exactly the same, except it's for the mace eth driver.
When I try to load the driver, I get:
/<7> divert: allocating divert_blk for eth0
//6> eth0: MACE at 00:05:9a:a0:51:88, chip revision 9.64
But the installer keeps asking for a driver. This is with the "fixed"
installer at ftp://ftp.uk.linux.org/pub/linux/fedora-ppc/fc3-ppc/, so I
was hoping it would work. Was it fixed only for the bmac driver?
So my net install is dead in the water at that point. Another problem is
that the onboard scsi (53c94) isn't recognized. I have to hook my drives
up to the aic7xxx card for the installer to see them. Any ideas about
this? This isn't necessarily a huge problem since I can hook the drives
up to the card during the install, assuming I can get 53c94 to work for
the actual OS.
Finally, there are weird video artifacts in the installer, like garbled
columns going down the screen. In these columns, pixels are flickering
rapidly and seem to be a copy of the column 5 chars to the right... I've
seen some emails about this being broken somewhere in the 2.6 kernels,
but no solution. I then tried to boot using my voodoo3 card using
"video=tdfx", but then I don't get past the first "pmac_init" screen.
Any ideas here? Does the installer kernel simply lack drivers for tdfx
Any hints would be much appreciated.
I finally have Fedora running happily on my Motorola MVME-2700
single board computer. I'd like to thank Bret Hughes and Colin Charles
for responding quickly to my initial cry for help. Their responses
sent me down several useful pathways. Although I doubt anyone's
been losing much sleep over this issue, I thought I should close
the thread out by summarizing how I got it to work.
1) The kernel image on the CD distribution would not boot at all. I
used cross development tools on an x86 linux box to produce a bootable
kernel. If anyone ever needs it, I'd be happy to supply a .config
file that will work for these Motorola VME boards. The page
http://kegel.com/crosstool makes configuring an x86 linux box to
produce PowerPC code very, very easy.
2) I extracted the files in ramdisk.image.gz, and placed them in a
directory on the linux x86 box which would be the NFS server for
my diskless MVME-2700 target. This will be the initial root
3) I used rpm on the x86 box, with the --ignorearch and --root switches,
to install all the PowerPC rpms needed for the rpm command itself.
In most cases the post install scriptlet failed (probably because I was
running on an x86 box, installing PPC code) and in a few cases I had
to use the --nopre switch because even the pre-install scriptlet
4) I booted my PowerPC target, with the new root file system NFS mounted.
Obviously, since many of the scriptlets had failed, the rpms were
installed poorly, and the whole system was suspect. But the critical
thing was the rpm command did work on the target. So I now produced
a new directory (/newFedora) on the target, and created subdirectories
down to /newFedora/var/lib/rpm/tmp . I then mounted the iso image
of the first PowerPC in loopback mode, and reinstalled the rpms
into this new root directory (after initializing the rpm database,
of course). Since I was now running on a genuine PowerPC, the
scriptlets worked correctly, and my rpm installs were clean. I
installed virtually all the rpm packages I wanted at this point.
5) I rebooted with the "newFedora" directory as my root directory, and
virtually everything was perfect. I had to configure the network,
and for some reason /etc/fstab had no entry for /dev/pts (which
prevented ssh logins to the target), but after fixing those minor
issues, I had a fully working Fedora machine. What luck!