*** Bug 219313 has been marked as a duplicate of this bug. ***

Any better if you hold down SHIFT while it starts?

Okay, it asks display related questions.

1. Load boot graphics
2. Detect display size

* y/y : hang
* y/n : reboot
* n/X : much better.  successfully loads text installation menu.  takes a looooooooooong time to load sata_via.  Console shows IDENTIFY timeouts and fails to detect attached devices.  Installation menu loads but cannot install as drive and cdrom are not detected.  This seems to be the infamous via IRQ quirk bug.

[Cc'ing Hannes]

Hannes, does openSUSE-10.2-Beta1 kernal contain via IRQ quirk fix?  If so, this needs to be chased further.

Sorry, I can't do much about the crash in the graphics without sitting
in front of such a machine. It's the only such report so far.

On a side note: you really see not a single new message after confirming
both questions?

Moving the bug to Hannes for your question.

Ahhh... Weird.  y/y reboots now.  I can swear that it hung once w/o printing any further message.  So, y/X reboots, n/X successfully loads text installer.

Which IRQ quirk fix? If that's something from libata-dev, there is a fair chance we've missed that one. Can you attach it here?

http://marc.theaimsgroup.com/?l=linux-kernel&m=116300291505638&q=raw

No, it's not included. Do we really have to use this 'pci_find_present' bit, too?
Can't we just strip it down to the bare minimum (ie that actual quirk fix)?

I'm testing via-c3 and the fail messages aren't consistent with IRQ quirk fix.  10.2b1 kernel w/ custom config where sata_via is built in works fine but loading sata_via.ko during boot gives BUSY state in prereset.  I'll report when I know more.

I'll ask Alan about the quirk fix.

I can confirm the Suse 10.2 DVD will not boot in a C3 pc. Mine is the Epia M6000. Following the instructions above I was finally able to get Linux installation to proceed by holding down the space key during DVD boot and selecting the text only installation by typing LINUX at the command prompt. Yast graphics is now running and installing the OS. This is new to Suse. 10.0 and 10.1 did not suffer from this. Hope this helps.

Please try 'irqpoll' kernel option.

I can also confirm SuSE 10.2 GM doesn't install on a VIA EPIA board,
on which 10.1 and 10.0 worked fine (also 9.3 IIRC).  Like Kevin:
"Following the instructions above I was finally able to get Linux 
installation to proceed by holding down the space key during DVD boot and
selecting the text only installation by typing LINUX at the command prompt. 
Yast graphics is now running and installing the OS."

However, it hangs when it reboots after completing the initial install from
CD1.  (iow, booting from disk the first time).  Holding the shift key down
I get some debug info from Grub, which goes through a number of stages
saying "press any key to continue", but before I see any startup messages
from the kernel, the  machine resets.  Strange considering it was quite
stable when installing CD1.  I gave up and reinstalled 10.1 as I need 
this machine to work reliably :-(

nemesis:~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 533.440
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips        : 1067.99

I don't have such a board locally available, so I can't debug that
boot failure.

But if there is a very patient volunteer willing to try a (potentially
large) number of test ISOs, I can put some together trying to narrow
down the bug.

No problem, sign me in

I'm afraid my machine is in production use so I can't offer to test
ISOs right now.

Some clarification too: I have another data point:

10.2 installs and runs no problem on an EPIA M10000 board, which
is detected at 'CPU0: Centaur VIA Nehemiah stepping 01' at 1 GHz
(at least it runs OK after I updated the board's bios to rev 1.17beta,
but that's not your problem).

10.2 installs but fails at first boot from hard disk (as per this bug
report), on a lower-powered board, an EPIA 5000 containing 'CPU: Centaur 
VIA Samuel 2 stepping 03' at 533 MHz.  This board does however install
and run 10.1 just fine.

This looks like a grub failure. Occasionally the bootloader installation generates an invalid menu.lst file for grub.
This file contains the line

default

with a missing number. This results in the above messages and finally a system hang as grub is not able to start anything :-)

Alex, the missing number in the default parameter should be in
perl-Bootloader. Can you please check?

Jep, will take care asap.

For everyone with the bootloader crash: I've started to create test isos.
So, if you have time and want to try them, please move over to bug 231104.

thanks

Could you please check if this error still occurs with openSUSE 10.3 Alpha 4?

I'm half globe away from the machine.  I can test it after two weeks or so.  Is that okay?

Sure, I think this is no problem. Thanks in advance.

Hi Tejun,

any infos you can provide yet?

I completely forgot about this will test alpha6 soon.  Thanks.

The problem is still there with alpha6.  It reboots itself while loading boot loader.  Holding down shift and booting in text mode works.

I've just added a check for this via cpu bug; please try again with beta1.

@tejun:

Can you please attach the (maybe corrupt?) menu.lst? Because as described in comment #16 there should be no value assigned to the variable "default".

Umm.. menu.lst from where?

Location of the file is: /boot/grub/menu.lst

Or can't you access the system at all? My assumption was that the system is accessible due to hannes comment (#16) about an invalid menu.lst.

Hmmm... I can boot to the installer and there's no /boot/grub/menu.lst.  I don't think the initrd image contains menu.lst, is it?

Ah, sorry, my fault. I thought the error occurred in a already installed system. But that's not the case if I interpret your initial comment right.

So, if there's no installed bootloader at all (besides the one on the installation media), I dare to doubt that it's a perl-Bootloader bug because perl-Bootloader didn't run at this point of time during the installation process.

I recommend to assign the bug back to steffen, but I don't know exactly.

see comment 19

*** This bug has been marked as a duplicate of bug 231104 ***