** Description changed:
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
+ 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
+
+
+ [Test Case]
+
+ On a system with qemu-system-ppc installed (KVM or emulated, both are
+ fine):
+
+ qemu-system-ppc64 -nographic -vga none -M pseries -cdrom
+ /path/to/ppc64el/mini.iso -device virtio-net-pci,vlan=0 -net
+ user,tftp=/does/not/exist,vlan=0 -boot order=nd
+
+ The network boot should always fail, and with trusty-updates' 20140630
+ +dfsg-1ubuntu1~14.04 the subsequent CD-ROM boot will also fail. With the
+ bug fixed, the CD-ROM boot will succeed and a GRUB menu will appear.
+
+
+ [Regression Potential]
+
+ Minimal. The patch is clearly correct, as all three callers (all in the
+ Ethernet driver) already expect the function to take arguments in that
+ order. The only risks are that the larger buffers will cause other
+ objects to shift around, or something else could depend on the reliable
+ memory corruption from the Ethernet driver.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1503929
Title:
trusty-updates qemu-slof network boot breaks subsequent OpenFirmware
operations
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1503929/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
