Red Hat Bugzilla – Bug 139146
Anaconda can't find kudzu, aborts install
Last modified: 2007-11-30 17:10:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
SV1; .NET CLR 1.1.4322)
Description of problem:
First, this appears that it might be the same as bug #119447 against
FC2 but which is closed and claims to have been fixed in FC3.
In any case, I have a generic P4/1.7GHz system, 1gig RAM, 2x 20gig
drives w/ software mirroring, onboard LAN, etc. I had experienced
bug #119447 while trying to install FC2 on this same system but
didn't have an urgent need to get it installed and by the time I got
back to it FC3 had been released.
In any case, I've been trying to get FC3 installed and seem to be
running into the exact same bug. Incidentally, this is the only
system I've ever had install issues with and I did manage a quick FC2
install by mounting the drives into another system, installing, and
then putting them back into this system where they worked fine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Start installation, select a custom install, select a minimal
install, and go.
Expected Results: Expected a working FC3 installation.
See anacdump.txt file to be attached as soon as I figure out how to
Created attachment 106636 [details]
Too big up upload uncompressed
There are a lot of db errors in the log which have me wonder about
writes to the disk not succeeding. Does it do better if you boot with
Saw that as a suggestion for another bug report and tried it last
night....same crash. I'll see if I can do it again and upload the
dump with ide=nodma set.
Created attachment 106772 [details]
Anaconda dump w/ ide=nodma
Here's the anaconda dump when installing with ide=nodma. I also deleted the
partitions on the second drive and made a simple partitioning scheme w/ ext3
partitions on the first drive to see if software-RAID was causing any problems.
Anyone have other suggestions to try? This system works fine with
Windows and is the only box that I've ever had problems with Linux on.
The motherboard is an ECS P4S5A2, is running the most recent BIOS,
and appears to use an XP4 (?) northbridge. The primary IDE
controller reports to be a SIS 961. Given the ide=nodma suggestion
earlier, I've even tried installing using an add-in PCI IDE card
(which uses the CMD649 chipset).
The install CD-ROM passes the self-check and the ISO that it was
created from has a valid md5 sum. I've also attempted to do an HTTP
install (booting via PXE).
The motherboard supports either PC133 or DDR266 RAM, and I've tried
with both (not at the same time). I've tried disabling all cache
options in the BIOS. I've even swapped video cards (both are AGP).
I've tried booting with acpi=off, apm=off, nousb, pci=bios,
pci=nobios, pnpbios=off, etc.
I've tried using LVM partitioning, and making the root filesystem
ext2 rather than ext3.
I've also just completed an attempt at installing with a 9gig SCSI
drive attached to an Adaptec 2940UW controller (with the IDE drives
unplugged from the motherboard).
No matter what, every install fails with the same error. Would I be
correct in guessing that this is some sort of incompatibility with
the motherboard itself? If so, what options are available for
tracking this further?
Ok last comment (unless someone can suggest something).....
I did some regression testing - FC3 is obviously having problems, FC2
produces the same error, as does FC1. However, RedHat 9 installs and
runs without any problems!
I suppose I could try doing an upgrade to FC3 and see what happens,
but would like some feedback from someone in the know to see if that
would even produce any useful results. I'm a little out of my league
trying to debug further.
I also get this exact same error on FC3.
I have a IBM NetVista 6833 P4 system. I tried a FTP and HTTP install
and after installing all the packages it crashes out. Using a
recovery CD it looks as if everything installed fine up to the point
I also have a anaconda dump if you would like to see it, but it looks
the same as the already attached.
I've finally given up. I put the drives into another system,
installed FC3 without a problem, and then put the drives back into
this system which is now working fine. The box will be going into
production tomorrow so I won't be able to do any additional testing
This is the same bug as #106372
*** Bug 140284 has been marked as a duplicate of this bug. ***
I submitted a similar bug (bug #140284) about a month ago. Same
problems. I've likewise tried a variety of command line args and
such, to no avail. If you would like additional information
(anacdump, specs, ...) I'll be happy to provide them.
PLEASE NOTE, though, that I WAS able to install and am currently
running FC2. This is (to me) a new problem in FC3.
I have the same problem as Jason (#11). FC2 instals without any
problems. FC3 experiences problems described above in the text and
graphical installation mode. The install media (DVD ISO image) is
checked and ok. I tried different command line options described in
comments to many bugs. Without results.
P4 1.4GHz, Mainboard ECS P4VXASD with latest BIOS (48bit LBA), 512MB
RAM, 160GB HDD. System is multiboot with Windows and FC2.
Because of its size, dumps and logs may be deliveried if will be
Some errors from ttys:
rpmdb: PANIC: fatal region detected; run recovery
db4 error (-30978)
No volume groups found
/usr/sbin/kudzu can not be run
I got FC3 to install, but in a very limped and backwards way:
1) Install FC2, standard install. No prbs.
2) Install FC3 as upgrade with the DO NO MESS WITH THE BOOT LOADER
option on. Install gets past death point at the window labeled "Post
Installation configuration" but shows "rpmdb panic: run recovery" all
the way up the screen.
FC3 seems to boot fine, and I am typing the bug report on it now.
HOWEVER, an attempt to install additional packages via the
"start">system settings>add/remove applications util brings up the
Packages Not Found
The following packages could not be found on your system.
Installation cannot continue until they are installed.
followed by a long, long list of packages not installed.
I don't know what quite to think of this, but I'm going to follow my
more-than-likely red herring intuition and try to install FC3, clean,
with no boot loader, hope that works, and install boot loader
manually. Will report back when I've got some results.
Created attachment 109172 [details]
Jason's "successful" install of FC3 via upgrade form FC2
Procedure in #13 is not the problem solution. You obtain strange
compilation of FC2 i FC3, which cannot fully operate. I think that
the problem is somwhere between the rpm database or hardware. I
compared the results in text and graphical installation. The text
installation aborts somwhere in the middle of rpms installation with
totally wasted screen. The graphical continues to the postinstalation
procedures. However, in the graphical environment errors observed on
tty (console) occurs earlier, after installation of openssh in my
case. In my case and in #13 problems are connected with rpm database.
Not everything is installed - ex.: kudzu is not present what I
checked manually. On the other hand, there are people who perform
this installation without problems. So, it may be connected with
hardware. I have no idea what to do. It is my third day (and night)
with this problem. The most strange is that FC2 installation is
Agree with #15. Sorry if I messlead anyone, I certenly did not mean
this to be a work around, just some valuable information.
Installing w/o GRUB lead to the same errors as reported before. I'm
out of ideas.
Some additinal tests were performed by me. I installed FC3 on Virtual
PC on the same machine. The installation proces achieved reboot
Only 2 errors were observed during installation on tty6:
No volume groups found
No volume groups found
The first appeard after the detection of the installed systems.
The second after the settings for partitions were established in Disk
So, I'm sure that the installation media is not the problem. I
performed the minimal instalation. After reboot, I obtained very
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" ....
and the above continues to infinity. These errors may be casued by
Virtual PC, it works fine only with MS OSes. The conclusion is that
errors in the FC3 installation process depend on hardware or disk
Installation from CD-ROMs (not DVD) gives the same results as in #12.
Do you have any idea what to check in my system?
Unless I'm missing anything, everyone experiencing this bug seems to
have a Pentium 4 in the 1.4-1.7GHz range...
IMO it would be interesting to know what "/sbin/lspci" and "cat
/proc/cpuinfo" say on the affected systems -- it would be interesting
to see if any other patterns emerge.
The respawning error in comment #17 is probably the bad interaction
between Virtual PC and the 4g4g patch. If I remember correctly, Fedora
Core 4's default kernel will not have 4g4g -- that will prevent the
probelm from happening when that release happens.
Comment #13 isn't the solution, sure, but it might allow somebody
experienced with RPM and/or Berkeley DB to look at the database and
see what kind of corruption is happening. (Chances are that the RPM
database will be too big to attach to this bug, however.)
Created attachment 109505 [details]
Hardware info for ECS P4S5A2 / P4-1.7GHz system
Output from /proc/cpuinfo and lspci
Created attachment 109521 [details]
cpuinfo and lspci under FC2
"cat /proc/cpuinfo" and "/sbin/lspci" made under running correctly Fedra Core 2
In my opinion the problem is not in processor type. I described
installation under Virtual PC because it uses the processor which is
mounted on board and gives the rest of environment, bios, hardware
emulation, etc. There was no problem during instalation till reboot
oposite to the "real" PC. I think, that problem depends on hardware
or disk configuration, but no processor.
I may perform additional tests, ex: on rpm databases, but someone
have to tell me what to do, because I am not so experienced in Linux.
Is someone working around this problem? I saw the same (or very
similar) problem in bug #141084 which has still status NEW. I may
help, but I'm not expert in linux. It is importatnt to me to obtain
solution or to know that there will not be any solution. I have to
choose linux distribution in a short term.
I suggest to increase the priority of this bug to high. I cannot do
that. Only the owner or submitter of the bug, or a sufficiently
empowered user, may change that field. I saw some bugs devoted to
this problem, ex. bug 119447 for fc2, which was closed without any
explanation as solved by the current release, ie. fc3. I think, that
problem has no solution yet and only the group of computers affected
by this bug changed as the release changed, because I can install fc2
without any problem.
I seem to be unable to change the priority as well. I guess we need
to get Jeremy Katz to weigh in with his thoughts. So far, I've seen
only one comment from him regarding this bug.
Created attachment 109640 [details]
Specs for my system
So, we have a full review of computer chipsets and periferials as may
be conluded from attachements: SiS, VIA, INTEL. They are not
especially exotic. I cannot see nothing similar. Maybe you will find
out something. Processors are really similar but no identical. Maybe
processor is relly the problem. But it is opposite to my tests with
Virtual PC. I have no idea. I tried to install with removed
unnecessary periferials, such as additional USB 2.0 PCI controller,
additional video card and without results.
Virtual PC is not a 100% transparent virtualization. That's why it
fails to boot FC3 after installation. If this is a processor-related
issue here, then Virtual PC could be changing thngs enough to keep it
from happening in that case.
> Processors are really similar but no identical.
AFAICT they're all the same core (Willamette).
Does anaconda apply microcode updates? I doubt it; it would be
interesting to make a version of the FC3 installer that applies
microcode updates shortly after boot, and see if that fixes the
problem at all.
That gives me another idea for trying to get some more clues, but I
don't have time to describe it right now. I should have time in the
next day or so.
I understand that Virtual PC is not 100% virtualization, but uses the
processor installed on motherboard and does not emulate it, if I
understand how VPC works. I only stated, that installation goes
further on VPC than on real PC using the same processor - nothing
more, and it was my aim. Errors after reboot may be casued by VPC.
Problem with VPC is for separate bug, but not this. I cannot achieve
postinstallation procedures and reboot after installation on "real"
PC and this is my problem and all of us.
Your observation about the core of processors is interesting. We are
waiting for any idea of solution. On my computer, FC2 installs
without problems. Problem is with FC3. Why anaconda in FC2 does not
demand microcode update? I do not expect downgrade of procedures in
anaconda. It would be strange. However, I may be wrong.
I never implied there was any "downgrade of procedures in anaconda".
Rather, I'm thinking it could be a strange CPU bug which hits only
under very specific circumstances, or something of that kind. In that
case, it may be fixed by newer microcode -- that's why Intel releases
the microcode updates in the first place.
Hopefully I have something for you to try in the next day or two.
(Maybe even in the next few hours.)
You may be right. But those circumstances may be very specific. I may
debug installation or gather additional information from system, but
I need guide "what" and "how".
I'm working on that right now.
I'm waiting :-)
Created attachment 109679 [details]
floppy disk with microcode driver/util/data for testing
These instructions assume you have a working Linux system that you can use for
creating a floppy disk. If you don't (e.g. if you have to create the disk from
Windows), my next attachment will probably be easier to use (but functionally
1. On a working Linux system, download the attachment and save it as
"microcode-disk.img.gz" or something like that.
2. Insert a floppy disk and run the following command to copy the file's
contents onto the floppy:
zcat microcode-disk.img.gz > /dev/fd0
3. Boot into the Fedora Core 3 installer on the system which shows this bug.
4. Skip the media test (you've probably done it already, I assume).
5. Once the "Welcome to Fedora Core" screen appears, press Control-Alt-F2.
6. Run the following command:
tar zxvf /dev/fd0
You should see the following output before the shell prompt reappears:
If you see any errors about timestamps being in the future, just ignore
7. Then run the following command:
8. It will produce about half a screen of output. Write down the lines of
output that start with "./microcode_ctl" or "microcode:". This will probably
be the first two lines and the last line or two. When you get a chance,
type that information into this Bugzilla bug.
9. Press Alt-F1 (for a text install) or Alt-F7 (for a graphical install) and
proceed with installation. See if it works this time or if it still has
Created attachment 109681 [details]
microcode driver/utils/data tar file for testing
Here are the steps that differ from the previous attachment's instructions:
1. On a working system, download the attachment and save it as
"microcode-test.tar.bz2" or something like that.
2. Copy that file onto a floppy disk.
6a. Run the following commands:
mount /dev/fd0 /x
tar jxvf /x/microcode-test.tar.bz2
You should see the following output from the tar command before the shell
If you see any errors about timestamps being in the future, just ignore
6b. If step 6a doesn't work, try again with these commands instead:
mcopy a:microcode-test.tar.bz2 .
tar jxvf microcode-test.tar.bz2
All of the other instructions remain unchanged.
OK, I'm starting test.
OK, I have perfomed test.
Output you ask for:
./microcode_ctl: writing microcode (length:208896)
./microcode_ctl: microcode successfuly writen to /dev/cpu/microcode
microcode: CPU0 updated from version 0x0 to 0x13, date 07162002
Installation process goes to the reboot without any problems.
However, after reboot, system starts and freezes in line
"checking for new hardware".
You waited so long because I have performed two installation minimal
and then everything (second takes on my computer more than hour).
After minimal installation system starts in runlevel 3 and freezes in
After everything installation, runlevel 5 starts andsystem freezes in
graphic interface in above line too and only a sign in the top right
corner turns around. After a some time system changes to text tty1.
The graphic environment may be returned by Alt-F8 but is still
frozen. I was waiting about 5 minutes and nothing happened, hdd does
not work - silence.
Your procedure is really a step forward :-)
but something should be corrected more :-(.
Do you have any idea? Now I believe that problem is with the
processor. You were right.
Wow... we have progress!
BTW, what version of Windows did you use to run Virtual PC? I think
Windows XP (and maybe 2000 as well) also applies a microcode update so
that may be why it worked under Virtual PC.
Anyone who has this problem should check if a BIOS update is available
for their computer. If so, they should apply it -- a new BIOS often
contains microcode updates, and it's better for the BIOS to apply it
than the operating system, if possible.
If anyone who is hitting this bug is also running the latest BIOS,
that would be a useful piece of information to know.
Chris, regarding your current freeze problems, I might have some
advice later today, or maybe tomorrow.
You right about windows :-) I did not know that windows updates
microcode. It is for me really new information.
I have the newest possible BIOS for my mobo (if I remember this BIOS
is about 2 years old). I had to update BIOS, because I had mounted
160GB HDD and my old BIOS had problems above 120GB, so LBA 48 bits
was instaled with new BIOS and works correctly.
Maybe new microcode should be installed during fedora startup?
Unfortunately, at the stage when it freezes any tty is not available.
Only Ctr+Alt+Del works :-)
So, Barry, thank you very much for help and cooperation. We really
have progress. I am waiting for your next advices :-) I am working
some time with computers, but today i feel as a student. It was a
good lesson for me. Thanks.
I think that someone else should perform your procedure and we would
compare results. Stuart, Jason, Eric - we look for volunteer! ;-)
For me is enough for today. Please tomorrow :-)
I am also running the latest BIOS made for my system.
At the moment I can't test the microcode hack because I am now using
the machine for several services. I was able to get FC3 installed
and running by installing the HD in another IBM P4 system, also a
Willamette 1.6GHz oddly enough. It installed fine and I moved the HD
back to my troubled system and it has run flawlessly now for a few
weeks. After the install Kudzu had no problems whatsoever.
Chris, does FC3 update the microcode during boot before Kudzu runs
(the "checking for new hardware")? If not you should change the order
of the init scripts so the microcode gets updated first.
BTW: When FC3 runs the microcode update at boot I get updated from
"revision 0x3 to 0x12, date = 07162002"
In the perfect world, the BIOS updates the microcode to a sane level.
If there is a new bios, please upgrade to that (even though the
changelog of the bios vendor usually doesn't mention microcode
updates, they often do include them silently)
The OS doing this behind the bios' back is rather awkward, and it can
even be dangerous in that the bios may still work around issues that
no longer are in the cpu, and that may even blow up.
Arjan, as you said: in the perfect world. But in real world we do
have updated BIOSes by the most recent releases available for our
mobos. Our mobos are not new rather.
Have you any suggestion, idea or better solution than microcode
update in OS? What should I do?
If there are no better solution I would like to incorporate a newer
microcode into Fedora. The system is installed but freezes on the
hardware check. No ttys are available at this stage. I may boot
Knoppix from CD and correct demanded files. Do you know what should
be gathered (files, tools, guides, howtos, etc.) and how to perform
this operation or where may I find such a procedure? Eric wrote
something about init files. May I ask for more precise explanation?
Maybe any other suggestion?
SUCCESS!!! This message is writem from running Fedora Core 3!
So, I describe the full procedure:
1) Install system according to Barrys comments #35 and #36 and reboot
system as demanded at the end of installation.
2) If your system works correctly - just work and dont read the
3) If your system freezes on "Checking for new hardware", as mine, you
may try the following (the idea is based on Erics comment #41 - thanks
Eric :-) )
3a) Extract from attachment in Barrys comment #36 file microcode.dat
and write it into floppy.
3b) Run any linux bootable from CD, ex.: Knoppix and connect to
partition with fedora.
3c) Rename /etc/firmware/microcode.dat to microcode.dat.orig (you may
revert then to the original in case of any problems)
3d) Mount floppy and copy microcode.dat into /etc/firmware/
3e) Open file /etc/rc.d/rc.sysinit and go almost to the end. You find
comment "# Now that we have all of our basic modules loaded and the
3f) BEFORE the above comment, write in a new line as follows:
3g) Restart computer - my works fine after that.
I know that this procedure is not convenient - but it works and I will
test if everything works fine.
The best would be to prepare a floppy used during installation - my
knowledge is to poor - maybe someone try to prepare such a floppy?
I would like to thank especially Barry:
- Barry this is your solution - not mine - thank you very much! :-)))
and thanks to everyone who worked around this bug :-)
I think that more convenient solution should be prepared and so more
important, correctness of may solution should be confirmed. If
demanded, the solution should be corrected
Best regards, Chris
Looks like we need to make sure the microcode service gets installed
and started by default on these machines.
Chris, that is a pretty complicated way. Guess I didn't get that
e-mail out to you fast enough ;-).
If the installation goes okay and the reboot into the system doesn't,
you can start FC3 in single user mode (init 1). At the grub prompt
hit 'e' and add 'init 1' to the end of the boot command. If I
remember correctly no services get started so kudzu shouldn't run.
Now you should be able to turn on the microcode service by typing:
chkconfig microcode_ctl on
and you may turn off kudzu if you wish:
chkconfig kudzu off
The microcode already in /etc/firmware/ is the same one that is
attached in this bug report.
Now reboot and all should be well.
Eric, you right.
The service is turned off.
[root@AAA ~]# chkconfig --list microcode_ctl
microcode_ctl 0:off 1:off 2:off 3:off 4:off 5:off 6:off
I will check your procedure in a few days and describe results.
Now I want to have some fun with FC3. I was waitng for correct
installation over a month :-). I have just installed the driver for
nvidia GForce and have to perform some other configurations.
Thanks & regards, Chris
Re: comment #44 and #45
No, that's not my solution for once the system is already installed.
Mine would be virtually identical to comment #45. FC3 does ship with a
slightly older version of the microcode updater and the microcode data
file, but the Willamette CPU core is old enough that it makes no
Re: comment #42
Yes, it's awkward for the OS to update the microcode. For what it's
worth, Windows XP does it by default -- but this caused a problem with
Service Pack 2 on Prescott CPU's:
Intel's and Microsoft's recommended solution is a BIOS update. If
that's not possible, Microsoft has an update to the Windows XP
microcode loader/data. Unfortunately I don't know if the MS update
uses more recent Prescott microcode or if it just disables microcode
updates on those CPU's.
Created attachment 109882 [details]
Anaconda dump, lspci, and cpuinfo.
I too encountered this bug. I have attached my Anaconda dump, lspci output,
and cpuinfo output.
My system board is an Elite Group P4VXASD2+ PCB 5.x running the latest
available BIOS. (http://www.ecsusa.com/downloads/p4vxasd2_5x.html)
Comment #35 resolved the problem from me, and this was the output from the ./m
./microcode_ctl writing microcode (length 208896)
./microcode_ctl: microcode successfully written to /dev/cpu/microcode
microcode: CPU0 updated from revision 0x0 to 0x14, date = 07162002
I did not have to perform the steps noted in Comment #44 or Comment #45. The
system rebooted and ran find with chkconfig showing microcode_ctl off.
(In reply to comment #48)
> Created an attachment (id=109882) 
> Anaconda dump, lspci, and cpuinfo.
> I too encountered this bug. I have attached my Anaconda dump, lspci output,
> and cpuinfo output.
> My system board is an Elite Group P4VXASD2+ PCB 5.x running the latest
> available BIOS. (http://www.ecsusa.com/downloads/p4vxasd2_5x.html)
> Comment #35 resolved the problem from me, and this was the output from the ./m
> ./microcode_ctl writing microcode (length 208896)
> ./microcode_ctl: microcode successfully written to /dev/cpu/microcode
> microcode: CPU0 updated from revision 0x0 to 0x14, date = 07162002
> I did not have to perform the steps noted in Comment #44 or Comment #45. The
> system rebooted and ran find with chkconfig showing microcode_ctl off.
Yeeesh! That's what I get for trying to talk to my children and type this up at
the same time. "problem from me" should read "problem for me". "ran find"
should read "ran fine".
The lspci and cpuinfo files in your attachment are both corrupted beyond
recognition (at least for me). unzip doesn't give me any errors, it's just that
the output files are unreadable garbage. The anacdump.txt file came through however.
I would strongly suggest running 'chkconfig microcode_ctl on'; if you need to
use my attachments/instructions from comment 35 or 36, and if that lets you
install, that means (a) your CPU has a data corruption bug and (b) the BIOS is
failing to apply the microcode update that fixes it. That means the OS has to
apply it instead (the alternative seems to be data corruption). And the way to
make Fedora Core do it is to make sure it runs the microcode_ctl service at each
Don't bother attaching any more lspci output to this bug unless anyone else asks
for it. It's probably irrelevant at this point. The contents of /proc/cpuinfo
may still be useful though.
To clarify my last comment: Matt, in your case, the contents of /proc/cpuinfo
will be useful. Your system seems to be updating with a different microcode
revision, so I'm wondering if it's a different CPU stepping that what we've seen
I've had success too!!!
I did the microcode update (comment #36) and got the same output as
commetn #38. HOWEVER, I did not have to do anything in comment #44 /
comment #45. Basicly, I did the microcode update and it worked!
Thanks so much, guys!
In case I didn't make it clear enough earlier: The microcode update
has to be reapplied *with every reboot*. This isn't a very big deal to
set up: you just need to run "chkconfig microcode_ctl on" (as root)
after the system is installed. Then reboot, or (if you *really* don't
want to reboot) run "/etc/init.d/microcode_ctl start". Afterward,
Fedora Core will automatically reapply it.
If you don't activate microcode_ctl, then the CPU's data corruption
bug will still be present in the running system and could still cause
problems down the road.
Sorry, missed that somehow. Thanks.
There's something else I should clarify: My workaround is *not* a full
and final fix for this problem (but it's better than nothing, of course).
I've read through some of the Intel CPU documentation, and I now think
that a real fix for this problem (for people who have already updated
to the latest BIOS) is going to involve running something off a
FreeDOS bootable floppy, or something along those lines. (This would
be a one-time matter, not something that needs to be done at each
boot.) Perhaps I'll elaborate on this later.
Created attachment 109917 [details]
this is a bit closer to a real solution
1. Download the attachment and save it as "microcode-boot.img.gz" or whatever.
2. zcat microcode-boot.tar.gz > /dev/fd0 (or the equivalent), with a formatted
floppy disk in the drive
3. Download ftp://ftp.heise.de/pub/ct/ctsi/ctmc10.zip and unzip it somewhere.
4. Copy the file ctmc.exe (from ctmc10.zip) onto the floppy disk. (You have to
copy it onto the floppy separately for licensing reasons.)
5. Boot from the disk and follow any instructions. It will ask for permission
before installing the microcode update into your BIOS. It may take a while to
read everything off the floppy disk.
6. When/if the update finishes sucessfully (see below), turn the computer off
and back on, and repeat step 5. This time, the computer should see that the
latest microcode is already installed, so it won't reinstall it (it won't ask
Unfortunately I have only one test system at home that gets as far as asking
for permission, and then it suddenly goes to sleep and won't wake up until I
press the reset button. However, while the update doesn't take, it still
doesn't do any damage. Also, this system is a Pentium II, not a Pentium IV, so
on a P4 things might work better.
When/if the update gets applied successfully, it will stick until the next time
the BIOS is flashed. Once this is in place, my previous method of updating the
microcode should no longer be necessary. (If you need to undo this for any
reason, just reapply the latest BIOS update.)
This is not quite the final word -- it would be better if the microcode
installer was open-source -- but it's less of a hack than my previous methods.
Give it a try and see what happens (but make sure you have all your data backed
Re: Comment #50 and Comment #51
My apologies Barry. No clue what happened to the zip. Anyway, I
turned on microcode_ctl as recommended and here's my /proc/cpuinfo.
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 0
model name : Intel(R) Pentium(R) 4 CPU 1500MHz
stepping : 10
cpu MHz : 1500.556
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips : 2957.31
I haven't had a chance to try the suggestions from Comment #56.
*** Bug 141084 has been marked as a duplicate of this bug. ***
Comment #56 has consistently failed on any computer I've tried it on,
thus far. :(
*Maybe* I'll see if I can write a microcode flasher this weekend. If I
don't get it done this weekend then I probably won't be able to do it
until at least summer, though.
Comment on attachment 109917 [details]
this is a bit closer to a real solution
Marking my attachment from comment #56 as obsolete, because it's simply broken.
This isn't something we can generally do as it will cause problems on other
CPUs. The main thing that can be done here is really just to lean on hardware
makers to fix their hardware :/
*** Bug 166961 has been marked as a duplicate of this bug. ***
*** Bug 160618 has been marked as a duplicate of this bug. ***
*** Bug 168579 has been marked as a duplicate of this bug. ***
*** Bug 179158 has been marked as a duplicate of this bug. ***
*** Bug 163220 has been marked as a duplicate of this bug. ***