I run 6.2 with the EATA disk controler driver. I perform an update from CD to RH7.0. The update request to use the diskdriver.img to find eata. Everything is fine. I reboot on the new kernel, it does not work: the new kernel did not make any provision to have eata included at boot time to drive the disk controler.
Passed to QA to reproduce.
I upgraded a bunch of computers and reached the following conclusion: - If lilo.conf before the upgrade, has a label 'linux' which is the default boot image, the upgraded kernel will include the correct disk driver and everything will be fine. - however, most of my computers, have 2 kernels: a 'linux', which is the base kernel of the install, then a 'bzImage' which is the default. In such a case, upgrading such a system will make 'linux' the default boot kernel, but this new kernel will not include the disk driver. Hopefully I can still boot on my old 'bzImage', recompile the source to make a new 'bzImage' incorporating the drivers then reboot. (after the 'make mrproper'-smp bug :-))
Well things are not so clear: I upgraded two more computers, each one having just a single 'linux' entry in lilo.conf. The upgrade went allright, I made rescue disk, but at reboot time, the kernels did not include the required disk driver! One was eata (again) but the other was AIC7xxx. To be able to reboot, I wanted to rebuilt the rescue disk again since the rescue did not contain also the correct disk drivers! (I wanted to build the rescue disk again since I made some mistake when copying a kernel made from another computer onto them). So, to rebuild the rescue disk, I restart completely the update process. This way the system would allow me to build new rescue disk and this time I knew what to do to correctly overwrite the kernel on the disk... First thing, anaconda wants to re-install packages that it just installed a few minutes ago! On one computer (fs), the first running of the upgrade processed about 1140 megs(!). The second running, just 118 megs. I made the rescue disk, recovered the kernel on it with a kernel made from another computer and was okay to get back control on the computer. On the second computer (lexis), the first and second running of the upgrade processed about 1140 megs also. But what is very strange is that, the 2th time, the installed kernel had the correct disk drivers! (aic7xxx). So there is at least 2 problemes: - why a 'just-upgraded' system, if upgraded again, requires a variable amount of data to 're-upgrade' a system instead of 0 bytes ? - why, sometimes, an upgrade will not correctly add required scsi disk drivers and sometimes it will ?? BTW: it would be really nice if a booting linux kernel, instead of panicing when realizing that it has no correct disk driver, ask for a driver disk... (all this with CD install since bootnet does not want of eata drivers)
Matt do you have any ideas?