Bug 723831

I'm definitely not seeing /usr/bin/vmmouse_detect included in the installer initrd.img.

# xz -d -c initrd.img  | cpio -it  | grep mouse
19875 blocks
xz: initrd.img: Compressed data is corrupt

Note, I'm seeing the "data is corrupt" message for the i386 and x86_64 initrd.img for both the 20110714 and 20110721 composes.  Could that be to blame?

(In reply to comment #1)
> Note, I'm seeing the "data is corrupt" message for the i386 and x86_64
> initrd.img for both the 20110714 and 20110721 composes.  Could that be to
> blame?

The same command on F-15 xz-compressed images works without error.  While there is no vmmouse_detect binary included in the F-15 ramdisk, it does however find other "vmmouse" files that are not present in F-16.

# xz -d -c /mnt/redhat/released/F-15/GOLD/Fedora/x86_64/os/images/pxeboot/initrd.img  | cpio -it  | grep vmmouse
usr/share/X11/xorg.conf.d/50-vmmouse.conf
usr/lib64/xorg/modules/input/vmmouse_drv.so
lib/udev/rules.d/69-xorg-vmmouse.rules
730528 blocks

What happens if you hit ^C right here?

(In reply to comment #3)
> What happens if you hit ^C right here?

I have test again, and hit ^C on that moment, but it still stuck there, nothing happened. Fedora-16-test-20110721-3-i386.iso still have this problem.

(In reply to comment #2)
> (In reply to comment #1)
> > Note, I'm seeing the "data is corrupt" message for the i386 and x86_64
> > initrd.img for both the 20110714 and 20110721 composes.  Could that be to
> > blame?
> 
> The same command on F-15 xz-compressed images works without error.  While there
> is no vmmouse_detect binary included in the F-15 ramdisk, it does however find
> other "vmmouse" files that are not present in F-16.
> 
> # xz -d -c
> /mnt/redhat/released/F-15/GOLD/Fedora/x86_64/os/images/pxeboot/initrd.img  |
> cpio -it  | grep vmmouse
> usr/share/X11/xorg.conf.d/50-vmmouse.conf
> usr/lib64/xorg/modules/input/vmmouse_drv.so
> lib/udev/rules.d/69-xorg-vmmouse.rules
> 730528 blocks

So does that mean the F-16 miss some 'vmmouse' related files?  Because it will go against this Alpha Release Requirements:
 
   Where platform support exists, all dedicated installer images (except efidisk.img, which offers no options) must boot to the graphical boot menu and allow the user to select install options. If no option is selected, the installer should load after a reasonable timeout.

should this bug been marked as an F16 alpha block bug?

(In reply to comment #5)
> So does that mean the F-16 miss some 'vmmouse' related files?  Because it will
> go against this Alpha Release Requirements:

My comment was only to demonstrate that the vmmouse* program indeed is not provided in the initrd.img.  Whether that's good or bad, I don't know yet.

> should this bug been marked as an F16 alpha block bug?

If it happens to everyone, all the time ... yes.  If it happens to a single person, or only some of the time under specific conditions, likely not.

Let's try to figure out why my F15 system doesn't exhibit the problem.  Does anyone else on test.org see this problem?  Can you double check that your ISO's are images checksum properly?

Is this a new KVM guest that you are just created, or is this an existing guest you are repurposing?  Is there any thing special with how the guest is defined?

Update ... I just saw the same boot error you mention in comment#0 ("failed to execute '/usr/bin/vmmouse_detect') ... however my system continues with loader and prompts me for language and keymap settings.

How much memory does your guest have configured?

(In reply to comment #6)
> (In reply to comment #5)
> > So does that mean the F-16 miss some 'vmmouse' related files?  Because it will
> > go against this Alpha Release Requirements:
> 
> My comment was only to demonstrate that the vmmouse* program indeed is not
> provided in the initrd.img.  Whether that's good or bad, I don't know yet.

Turns out that the initrd.img is created differently in Fedora 16 and the message "Compressed data is corrupt" is because we don't yet have any user-space tools that understand how to unpack the initrd.img.  We'll need something to inspect the images in userspace ... but that can be tracked on anaconda-devel-list@

(In reply to comment #6)
> (In reply to comment #5)
> > So does that mean the F-16 miss some 'vmmouse' related files?  Because it will
> > go against this Alpha Release Requirements:
> 
> My comment was only to demonstrate that the vmmouse* program indeed is not
> provided in the initrd.img.  Whether that's good or bad, I don't know yet.
> 
> > should this bug been marked as an F16 alpha block bug?
> 
> If it happens to everyone, all the time ... yes.  If it happens to a single
> person, or only some of the time under specific conditions, likely not.
> 

Yes, this issue even doesn't always happen to me, it only has the possibility to happen when I switch my current active window to some other ones ( make the cursor on some other programs ).

> Let's try to figure out why my F15 system doesn't exhibit the problem.  Does
> anyone else on test.org see this problem?  Can you double
> check that your ISO's are images checksum properly?
> 

It seems that this did not happens to someone else ... I have checked the images' checksum, and the results are fine as the following:

[twu@localhost f16-pre-alpha]$ sha256sum -c Fedora-16-test-20110721-3-i386-CHECKSUM 
Fedora-16-test-20110721-3-i386.iso: OK
Fedora-16-test-20110721-3-i386-netinst.iso: OK

> Is this a new KVM guest that you are just created, or is this an existing guest
> you are repurposing?  Is there any thing special with how the guest is defined?

I have tested on both new KVM and an existing one, and it has chance to reproduced on both situation ...

(In reply to comment #7)
> Update ... I just saw the same boot error you mention in comment#0 ("failed to
> execute '/usr/bin/vmmouse_detect') ... however my system continues with loader
> and prompts me for language and keymap settings.
> 

Yeah, I almost see this error every time, but there are only some times it will get stuck, and the prerequisites of making it not get stuck is that the cursor can't be moved.

> How much memory does your guest have configured?

I configured 1512 MB for memory.

Thanks Martin, looks like a fix is out for review already ... 

https://www.redhat.com/archives/anaconda-devel-list/2011-July/msg00144.html