I saw this bug while I was installing, and the installation failed(fresh install), I really don't know if this had anything to do with the cause, but I tried once again to do the install and it succeeded. The only thing that I did different was remove a DVD that I had forgotten to remove from my dvd- rom. Again, I don't know if that could cause the problem I saw, but I know that after removing the DVD and trying the install once again it succeeded without a single error. Also during beta4 I had a very similar problem with my USB compactflash/smartmedia card reader plugged in. Failed the install, unplugged the reader and tried again and install went off without a hitch.
Aleksander Adamowski <[EMAIL PROTECTED]> said: > 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. > > > > -- Just when you think you were making progress you realize that you were facing backwards.
