gfxboot infinitely loops with today's hardy DVD images

Bug #204270 reported by to be removed
0
Affects Status Importance Assigned to Milestone
gfxboot-theme-ubuntu (Ubuntu)
Fix Released
Critical
Colin Watson
Hardy
Fix Released
Critical
Colin Watson

Bug Description

Binary package hint: gfxboot

Greetings from your friendly neighborhood QA team.

When testing today's hardy DVD images, in preparation for the Beta release, I found out that gfxboot inifinitely loops, or crashes, resulting in the DVD images to be unusable. The images in questions are hardy-dvd-amd64.iso and hardy-dvd-i386.iso from today (earlier ones have not been tested).

The symptom is that the machine (real hardware or kvm) boots, and shows the Ubuntu logo and the main menu (starting with "Try Ubuntu without any change to your computer"). It does not show the language selection menu that the desktop CD does. More importantly, it does not react to the keyboard in any way. I note that this can be repeated in both kvm and on real hardware, on both the i386 and amd64 DVD ISO images.

This obviously makes the DVD ISOs unusable.

Quoting an IRC discussion with Colin Watson:

<heno__> cjwatson, slangasek: Ubuntu DVD i386 seems not to respond to the keyboard at gfxboot
<heno__> liw has more details
<liw> I'm having that problem: it's both in kvm and on real hardware
<liw> if I disable gfxboot according to instructions in https://wiki.ubuntu.com/KvmVirtManagerEtc then the image boots in kvm and I can use the keyboard (but haven't progressed passed the boot: prompt)
<cjwatson> huh, odd
<cjwatson> is the real hardware USB?
<cjwatson> (keyboard)
<cjwatson> I'm not sure why the DVD should be different in this regard
<liw> read hardware usb keyboard
<liw> attached through a kvm (keyb/video/mouse thingy), but that has not been a problem at any other point
<heno__> liw: could you try connecting it directly or on a different box?
<heno__> (like a laptop)
<liw> I can try a ps/2 keyboard, but I don't have another machine to try it on currently
<liw> (my laptop does not have a working dvd drive at the moment)
<cjwatson> is this reproducible for non-DVD?
<liw> I have had no problem with non-dvd isos yesterday, in kvm (I have not tried any of them on real hardware)
<liw> but I did install on this machine and keyboard on... Monday, using the then-current cd image
<cjwatson> I have heard of problems with gfxboot and usb, though not been able to reproduce them myself
<cjwatson> a difference between desktop and dvd is baffling though
<liw> a ps/2 keyboard does not help
<liw> and with the ps/2 kbd, which has a caps lock led, it does not seem to react to caps lock, either
<liw> if it helps, I can try booting from a desktop cd, on real hardware
<liw> but note that the dvd symptoms are the same in kvm as on real hardware
<cjwatson> liw: I'd very much like to know whether the desktop CD suffers from this
<cjwatson> if the DVD is hosed, we can just not release it
<cjwatson> if the desktop CD is hosed, that would be an alarm bell
<liw> checking, burning is slow
<cjwatson> slangasek: is it deliberate that the beta announcement refers people to /ubuntu/hardy/+bugs for filing bugs? AIUI, that'll result in every bug they file being nominated for hardy
<cjwatson> I think perhaps /ubuntu/+bugs would be better
<liw> the desktop i386 cd works fine, and pops up the language selection menu and I can select a language and then stuff from the main menu
<liw> the i386 dvd does not even pop up the language selection menu
<cjwatson> guess I'm going to need to find some disk space to jigdo it
<cjwatson> it is reminiscent of the bug that affected Kubuntu
<cjwatson> indeed, identical in symptoms
<cjwatson> hmm, I might be able to just suck down its /isolinux/ directory
<cjwatson> liw,heno_: DVD bug reproduced with reduced test case
<cjwatson> EXACT SAME BUG as Kubuntu earlier in the week
<cjwatson> or rather, exact same location
<heno_> :(
<liw> is there an explanation why it only affects DVDs and not CDs?
<cjwatson> I hate hate hate Mandelbugs
<cjwatson> liw: different layout of things in memory :-/
<cjwatson> as in, the /isolinux directory is different in various ways, which happen to be enough
<liw> ok
<liw> I'll put my system back to its normal configuration, then
<liw> (good to know it's not because of the ps/2 vs usb keyboard, at least)
<cjwatson> I reproduced it by sucking down the /isolinux directory from the DVD build tree on antimony
<cjwatson> no, the keyboard thing was a red herring
<cjwatson> gfxboot is crashing
<cjwatson> or inflooping, but whatever
<cjwatson> I'll look at it, but I'm not optimistic about a fix today
<cjwatson> although that said, random permutations will make it go away
<cjwatson> I happened to have an extra entry in the F6 menu in my working tree, and that was enough to make it go away; but for all I know it might break other images
<liw> this does not sound nice
<cjwatson> it is not
<cjwatson> the crash is in assembly
<liw> oh right, and this is running in real mode, too
<liw> the full horror of the situation dawns on me
<liw> should I file a bug?
<cjwatson> probably in a malloc routine
<cjwatson> might as well
<cjwatson> on gfxboot, please
<cjwatson> it's not actually real mode
<liw> cjwatson, may I quote you from this channel in the bug report?
<cjwatson> err, at least not entirely; it uses 32-bit registered
<cjwatson> registers
<cjwatson> sure

Tags: iso-testing
Revision history for this message
Colin Watson (cjwatson) wrote :

dumpmem says:

009: addr 0x09fbf3, size 0xfffff7+0, ip 0x0000, free
oops: block at 0x09fbf3: size 0x000000 is too small

Hmm. Negative size?

Colin Watson (cjwatson)
Changed in gfxboot:
assignee: nobody → kamion
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

Binary-chopping with a slightly modified dumpmem eventually revealed the problem.

findfile returns a pointer to a chunk of memory corresponding to the file; menuconfig.init uses strstr on it, which means that it's expected to be 0-terminated, but isn't. strstr therefore walks off the end, which causes menuconfig.init to stick a 0 immediately after the end of the memory chunk corresponding to the file, which happens to be metadata for the next malloc chunk along. Thus (eventually, maybe) boom.

Colin Watson (cjwatson)
Changed in gfxboot-theme-ubuntu:
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gfxboot-theme-ubuntu - 0.5.11

---------------
gfxboot-theme-ubuntu (0.5.11) hardy; urgency=low

  * Backport 'split' memory corruption fix from SuSE.
  * Fix menuconfig.init memory corruption; strstr does not work on file
    contents unless they are guaranteed to be zero-terminated by some
    out-of-band means as is done for help texts (LP: #204270).

 -- Colin Watson <email address hidden> Thu, 20 Mar 2008 22:19:20 +0000

Changed in gfxboot-theme-ubuntu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.