Comment 0 for bug 1503929

qemu-slof 20140630+dfsg-1ubuntu1~14.04 from trusty-updates appears to corrupt memory during some network boot operations, while 20140630+dfsg-1ubuntu1 (utopic, identical source, but built with gcc 4.9 rather than trusty's 4.8) works fine.

For example, a "boot net" that performs a TFTP download (even if it connects but fails, eg. because the file doesn't exist, but not if it fails to DHCP or connect at all) causes a subsequent "boot cdrom" to fail. http://paste.ubuntu.com/12710600/ has examples to reproduce the good and bad cases, no manual DHCP/TFTP setup required.

Other manifestations of memory corruption include a TFTP-booted GRUB working fine except that the MAC address that GRUB uses for its own TFTP operations has its last octet replaced with 0xd1. This was originally noticed when MAAS failed to boot KVM instances, as it assumed the MAC that GRUB used matched the one that Linux knew about.

Both cases are fixed by using a qemu-slof built with gcc 4.9 instead of the 4.8-built archive version.

A tcpdump excerpt covering the final TFTP packet loading GRUB itself, and the first ARP from within GRUB:

  04:01:23.536384 52:54:00:55:40:13 (oui Unknown) > 52:54:00:17:ed:f1 (oui Unknown), ethertype IPv4 (0x0800), length 60: 10.10.0.107.2001 > 10.10.0.2.38623: UDP, length 4
  04:01:23.876989 52:54:00:55:40:d1 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Request who-has 10.10.0.2 tell 10.10.0.107, length 46