Bugzilla – Bug 251054
Will not start installation on C3
Last modified: 2007-07-11 15:07:25 UTC
I have VIA processor processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 733.489 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 : 1469.60 I was able to install the SUSE 10.1 on this machine without any problem. Under 10.2, 10.3 alpha, and mini-distro this machine will not start the installation. It will start the installation procedure, get to the point that says loading the linux kernel and reboots the system. I suspect but can not confirm, I might be hitting a bad instruction. I specifically pick the x86 version (32 bit). I am pretty sure, the equipment is alright, because I can boot off a live ubuntu cd without any problems.
Have you tried to use the 'failsafe' mode?
Can not try it. As soon as loading appears, the system reboots. There is no time to select anything.
The failsafe mode is a boot option - one that you choose before the kernel is loaded.
The reboot occurs at the very first kernel load. There are no prompts available to do a failsafe boot. This occurs during the cdrom initial startup. I do not know of any method,other than altering the cd itself to switch it to a failsafe mode. If so, I would appreciate the information. Remember, this is even before it comes asking if you want to install the or boot the system.
At the boot loader menu you can specify the failsafe option to boot?
(In reply to comment #5) > At the boot loader menu you can specify the failsafe option to boot? > I do not know how to make this clearer. I understand the install process works like this: 1. During the boot process of the computer, It goes to the cd and loads a bootstrap. 2. The bootstrap starts up and loads the installation kernel 3. Installation kernel starts up 4. It then prompts the user for the various options, e.g., failsafe mode, install, upgrade. The problem occurs between 2 and 3. Either the bootstrap reboots the machine or the installation linux kernel does. By the way this also occurs in Alpha 4.
That's not how the boot install process works. Step 1 is correct, but the boot loader offers a number of options, like: Boot from Harddisk Installation Installation - ACPI Disable Installation - Local APIC Disabled Installation - Safe Settings Rescue System Firmware Test Memory Test ... and then Step 2 happens, booting the installation kernel with the options specified by whatever boot choice you made. I'd still like to see if failsafe works, but I'm not expecting miracles. At first I suspected that it might be that the C3 doesn't support the cmov instruction. kernel-default just enables CONFIG_M586, so we don't depend on cmov.
I am not arguing about the process. The problem is occurring before any options are occurring. This is happening at the point where you are starting to load the basic boot loader. This is happening even before the installation options appear. As soon it starts reading the files from whatever media you are using, it reboots. This does not occur with fedora 6 or SUSE 10.1 It started to occur starting at 10.2. You can not even execute a fail safe since the reboot occurs before that time. I suspect that the intial set of instructions that start loading the boot loader is using cmov instruction, which is not implemented in the earlier versions of the C3. When I say the installation kernel, I mean the portion where you have those options you mentioned.
Ok, so it's just a disagreement in terminology then. Syslinux may use cmovl in its JPEG code. Either way, it's not a kernel bug, so I'm transferring it to the syslinux maintainer.
That would be bug 231104, then. Unfortunately it looks like we are running into a via cpu bug here. Not all via systems are affected (as it happens, the system I could access here works). I haven't found time recently to work on this, so the issue is at a standstill right now. *** This bug has been marked as a duplicate of bug 231104 ***