Description of problem:
While doing a graphical install of Fedora Rawhide (from March 7 am) I noticed
that I ended up installing 4929 out of 4927 (!) packages. One of the last couple
of packages was part of emacs.
I brought this up on the fedora test list and Seth Vidal said he thought he knew
what the problem was and asked me to file a bug verus anaconda.
Version-Release number of selected component (if applicable):
The version in the packages was anaconda-188.8.131.52-1.i386, but I am not sure if
that was what was in the initrd.img (netinst.iso didn't work so I used grub to
boot from vmlinuz and initrd.imf from the isolinux directory).
I only did it once.
Steps to Reproduce:
The cound of packages installed was off by 2.
The packages actually installed matching the number announced as expected.
This is from an email message on the fedora test list:
On Fri, 2008-03-07 at 19:34 -0600, Bruno Wolff III wrote:
> On Fri, Mar 07, 2008 at 18:24:58 -0500,
> seth vidal <email@example.com> wrote:
> > On Fri, 2008-03-07 at 17:04 -0600, Bruno Wolff III wrote:
> > > While doing an install of today's rawhide I ended up having 4929 out of
> > > packages installed. It isn't a big deal, but does seem odd.
> > >
> > Did you install using anaconda or was this an upgrade via yum?
> It was an anaconda install I got into by having grub point to a copy
> of vmlinuz and initrd.img from the isolinux directory (because netinst.iso
> was broken today) on x86_64. It was a graphic install with a custom
> file system layout and "customize now". I was anxiously waiting for it
> to finish so I was a bit surprised when it kept going after reaching 4927.
> One of the last two things had "emacs" in its name.
> The boot failed afterwards, but I think that was due to a mkinitrd regression.
okay - I know what that was and It is easy to fix. File this one in
anaconda - I think it is anaconda's transaction callback getting
confused due to the %posttrans call in the emacs package.
Seth -- do we end up getting the rpm callback with RPMCALLBACK_INST_CLOSE_FILE
again on posttrans?
yep. Those should be handled correctly on yum 3.2.11 and above, though.
Hrm, I seem to recall still seeing the wrong count very recently, in the last
couple days. Could it be that this isn't fixed then?
Yeah this is still broken.
Brute force hack for this committed in my tree