Hi! I were trying to hunt for that dreaded mkinitrd bug in RC1. First, I've tried to conduct an upgrade from 9.0 beta4 to 9.0 RC1 on my machine at home during the weekend, but during the packages installation process there was a power outage.
I've continued the upgradeafter the power had been restored, but some packages were left in a hosed state. The mkinitrd failed during that install, but since the installation of packages has been interrupted, I can't say that the bug really is here. Maybe some leftover beta4 packages were causing it. Second, yesterday I've tried to upgrade an old machine at work that has 8.2 installed. It has an old CD-ROM drive, so this time there were some errors about packages being not readable from the CD. The problem with mkinitrd also appeared - after the reboot there was no initrd-2.4.19-7mdk.img, but there was vmlinuz-2.4.19-7mdk. In /boot, the vmlinuz symlink pointed at the new kernel, the initrd.img symlink pointed at the old initrd. You know what are the results - kernel panic on boot. I've used the rescue mode from RC1 CD1 to mount filesystems, chroot, mount /proc and run mkinitrd manually, then correct symlinks in /boot and run lilo. But I still don't know for sure whether the mkinitd problem exists in RC1, or whether interrupted installations are at fault. Two installations in a row were hosed by external circumstances (power outage, defective CD-ROM drive?). Those things happen. So my suggestion is: make the installer fully bulletproof, so that you can literally pull the plug during installation. Particularly the packages installation phase - it takes the most time, it has the highest probability of being interrupted. E.G.: * When installing a portion of packages as a transaction: 1. create a file in the root fs named ".mdk9.1_install_transactions_to_perform" (or ".mdk9.1_upgrade_transactions_to_perform", depending on installation class). It should contain all the information about RPM transaction that is to be executed, and about all the transactions that are planned after that, and all the information about the state of installation that is needed to resume it in case of a failure. 2. after writing contents, close that file. 3. sync. 4. conduct the RPM transaction. 5. sync. 6. optionally, sleep for e.g. 2 seconds 7. rename ".mdk9.1_install_transactions_to_perform" to ".mdk9.1_last_committed_transaction" 8. sync 9. GOTO 1. * When ending "Install system" stage: 1. Delete the file ".mdk9.1_install_transactions_to_perform" and the likes from the root filesystem * When booting from the install CD, after initial installer steps: 1. ask the user for installation class (as currently, Recommended/Expert, Install/Upgrade/Upgrade packages only) 2. detect harddrive, locate the original root filesystem, see whether the files like ".mdk9.1_install_transactions_to_perform" exist. 3. try to parse the file to determine what transaction needs to be replayed (with --force) and how the installation is to be continued. If its contents cannot be parsed => there was a power down when it was being written to => try to parse ".mdk9.1_last_committed_transaction" - it is good with 100% probability. 4. replay the transaction mentioned in the file with --force (there is a chance that transaction was hosed, so better to replay it) 5. continue the installation according to data found in that ".mdk91*" file.
