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.
