Best guess is ISO filesystem support is not quite as mature as the others - actually, that is no guess, there are several "missing features" which could cause a problem depending on how the filesystem was built and with what features.

The ODW builds in Las Vegas were all installed from DVD and there has not since been an official firmware update which changed ISO filesystem support.

So, some DVDs work, some don't. This is definitely something already which is on the bug list.

@czp

after copying inst32 to my tftp server i was able to boot from it. Unfortunately i can't go on with the installation from the DVD as it doesn't work from a USB DVD drive.
So i tried to do a network installation but i had no more success trying TFTP (copied the DVD content to my tftp server), http or ftp ("no repositories found" with all FTP or HTTP servers i found on the web).

can you help me with it ? can you provide me with a working http or ftp source for installation ? maybe i'm making a syntax mistake ?

thanks !

PS : talking about Efika here, not pegasos.

I'm just downloading the installer DVD and will share my experiences later today. I have an USB DVD writer, which is not recognized by the firmware at all, but works nicely from Linux. Probably you need to load some USB modules by hand, but that problem should have been fixed long time ago :-)

Here are some working examples:

nfs on the home network:


ftp mirror in France:


or the same data can be entered using the menus. You can use names only if your DHCP server also assigns a DNS server, or you set it up in inst32.

thanks for the clear explanation Peter, i'll try that tonight from home.

Booted inst32 using tftp with the DVD in the connected USB DVD writer, and the installer booted directly into the graphical installer without asking any further questions.

So, a couple of questions arise:

* is your USB DVD driver supported by Linux? Then it should be recognized and media automagically found in it

* is the DVD correctly written / or can it be read by the given drive (the CDRW/DVD combo in my ODW can't read DVDs written by my USB DVD writer) Compare http://download.opensuse.org/distributi ... vd/MD5SUMS with md5sum /dev/sr0 (takes ages to complete...)

Well as per usual my Efika just seems to plain hate me. The DVD MD5 was fine, and the Efika picks up the drive and reads it at the firmware(it was burned with the same drive again to be sure). I wanted to do an internet install following that failure, and now I literally can't get anywhere with inst32. Trying to boot it from the USB key (from which the Debian one works fine) with or without the ftp option (e.g. boot hd0 INST32 blah blah) simply ends up leading to a screen worth of text (don't get time to write it all down, dealing with OF devices etc) that ends with:

Calling quiesce...
returning from prom_init

Then dumps me eventually back to the firmware prompt.
Even blanked the hard drive (there goes Debian...) and tried various partition combos. Basically I'm left with a system that runs E17KA from the other usb key right now and doesn't do much else as a result. Sigh...

Wow! I have never seen such a symptom. I had no problem booting inst32 from the net using tftp, from the built in HDD and from an USB HDD (I don't have an USB key, which would work with EFIKA). BTW: these messages are printed on each boot, just go away so quickly, that the screen is still blank due to a mode change before you could read it.
Q: is the MD5 of inst32 all right on your USB key? Here is the value for the one I just booted successfully from an USB HDD:


And another question: which video card do you have? I only tested using Radeon 9250 and GForce 4200, as XGI is impossible to get in this part of the world. I asked the SuSE guys to include support for it, but could not test, if it was really enabled.


Ooops, I'm sorry to hear it. You should do two things before doing such a drastic thing:
* ask here (so we can say, that it's not worth doing it...)
* make a backup, so you don't loose your work...

If you have a working DHCP and no proxy then the following boot command should drop you right into the installer:



It's in Hungary, so might be slow, but tested to work.

Of course, you need to give a boot device, if it is not on the default (hd0:0 for an USB key, eth:a.b.c.d,inst32 for tftp, etc.)

If your HDD is not yet partitioned with a swap partition, make sure, you also have an USB key or HDD connected to create a swap file / partition.

To be honest I don't mind losing Deb' for a little while or I wouldn't have done that. I play around with virtually every OS I can find anyway, so I'm used to letting things install over and over again.

I checked out the MD5 again and it matches perfectly, and the card is an Asus Radeon 9250 128MB that was recommended by Matt a while back which works fine with Deb, E17KA, Crux and so on.

I tried it with the HDD swap/normal partitions pre-made, totally unformatted, as fat32 etc just to be thorough, and DHCP has always been fine with the Efika.

Typing in the boot hd0 INST32 (etc) command:

The first part of the screen of text I get seems to deal with kernel uncompressing, "memory layout at init:" (lists some memory locations), "command line=(url typed in from above)" then the last few lines are (excuse the vagueness, having to do this a line or two at a time before it reboots so some parts may not be 100%):

Looking for displays
(something) rtas at (memory location) ... done
Applying EFIKA device tree fixups
copying OF device tree ... done
Building dt strings ...
Building dt structure ...
Device tree strings (memory location) -> (another mem location)
Device tree struct (memory loc) -> (memory loc)
Calling quiesce ...
returning from prom_init
(sits here for a while then reboots)

The Debian online/internet installer seems to still start up fine from the same USB key, but whether I give inst32 a url or just put boot hd0 INST32 I end up with the same results. Bit of a strange one then.[/img]

This is the exact same setup I have over here, and tested on multiple EFIKAs...

We need to know what is going on before it reboots; this is usually indicative of a kernel panic, but without that kernel panic details we could never tell what is going on.

You'll need a serial cable and to add console=ttyPSC0 to the kernel boot line - and get any details of the Linux boot process. It is obviously before the kernel framebuffer subsystem is loaded, but video=radeonfb would not be a total loss here too just in case :D

Unfortunately I don't have a serial cable nor would I really know what to do with one if I did. I know it provides debug info but that's about the limit of my understanding right now. ;)

I'll give another try at booting it from the internal HDD directly just to see if it boots, and from a USB HDD too. Holding on to a slim hope it might just be the USB key somehow. We'll see.

I would seriously consider investing in one :)

For your purpose it simply allows you to watch the firmware boot process and then output the very early pre-framebuffer data from the Linux kernel. This is not any information that you would not eventually see on the framebuffer, but if it crashes before it turns the Radeon on and writes the output buffer to it, then you are not going to see any of this, and it IS quite useful.

Is there any known instability with 10.3 and a Peg2/G3 ?

I'm running 2 Peg2 /G4 which work flawless, but my Peg2/G3 doesn't even do the install without locking.
On the installed System, I'm unable to write a large amount of data (from DVD or net ) to HDD without locking.

If I boot niktarix (2.6.14 kernel) on the same machine, the system can do everything without problems..

Does anyone have the same prob ?

Sorry, I don't have a Peg I. to test it...