Commissioning x86_64 node never completes, sitting at grub prompt, pserv py tbs

[Jason Brink]

[Impact]
When TFTP booting with UEFI, the TFTP server would stack trace when terminating the transfer. This would lead to some UEFI boot issues when using UEFI

[Test Case]
1. Install MAAS
2. Setup UEFI on machine to PXE boot from MAAS
3. UEFI boot machine, it will fail as tftp chrases.

4. With fix, UEFI boot machine, it will succeed as tftp doesn't crash.

[Regression Potential]
Minimal. This has tested and QA and proven to be working as expected.

ubuntu 14.04LTS + MaaS 1.5 on x86_64

Controller:
esxi vm xeon + vmnet3/ixgbe

Nodes:
supermicro twinblades
Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
128GB RAM
2@ ige
2@ ixgbe <<< used for PXE booting

Trying to add physical nodes configured for Trusty Tahr amd64. IPMI powerctl cycles the node, tftp's two boot files, then commissioning goes out to lunch:

15:12:11.465976 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:25:90:e5:5a:56 (oui Unknown), length 359
15:12:11.468982 IP 172.30.193.38.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
15:12:11.475270 IP 172.30.255.101.1294 > 172.30.193.38.tftp: 41 RRQ "bootx64.efi" octet tsize 0 blksize 1468
15:12:11.535326 IP 172.30.255.101.1295 > 172.30.193.38.tftp: 33 RRQ "bootx64.efi" octet blksize 1468
15:12:12.024716 IP 172.30.255.101.1296 > 172.30.193.38.tftp: 33 RRQ "/grubx64.efi" octet blksize 512

These tb's coincide with above traffic and node sitting at the grub prompt indefinitely:

2014-05-08 15:12:11-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a098>
2014-05-08 15:12:11-0700 [RemoteOriginReadSession (UDP)] Unhandled Error
 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 73, in callWithContext
     return context.call({ILogContext: newCtx}, func, *args, **kw)
   File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
     return self.currentContext().callWithContext(ctx, func, *args, **kw)
   File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
     return func(*args,**kw)
   File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
     why = selectable.doRead()
 --- <exception caught here> ---
   File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 234, in doRead
     self.protocol.datagramReceived(data, addr)
   File "/usr/lib/python2.7/dist-packages/tftp/bootstrap.py", line 171, in datagramReceived
     datagram = TFTPDatagramFactory(*split_opcode(datagram))
   File "/usr/lib/python2.7/dist-packages/tftp/datagram.py", line 394, in __call__
     return datagram_class.from_wire(payload)
   File "/usr/lib/python2.7/dist-packages/tftp/datagram.py", line 323, in from_wire
     raise InvalidErrorcodeError(errorcode)
 tftp.errors.InvalidErrorcodeError: Unknown error code: 8

2014-05-08 15:12:11-0700 [RemoteOriginReadSession (UDP)] Logged OOPS id OOPS-20c0e9854c8b0ef29998d4a27454fc6a: InvalidErrorcodeError: Unknown error code: 8
2014-05-08 15:12:11-0700 [TFTP (UDP)] Datagram received from ('172.30.255.101', 1295): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'blksize': '1468'})>
2014-05-08 15:12:11-0700 [TFTP (UDP)] Datagram received from ('172.30.255.101', 1295): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'blksize': '1468'})>
2014-05-08 15:12:11-0700 [-] RemoteOriginReadSession starting on 43143
2014-05-08 15:12:11-0700 [-] RemoteOriginReadSession starting on 43143
2014-05-08 15:12:11-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469aea8>
2014-05-08 15:12:11-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469aea8>
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2014-05-08 15:12:12-0700 [-] (UDP Port 43143 Closed)
2014-05-08 15:12:12-0700 [-] (UDP Port 43143 Closed)
2014-05-08 15:12:12-0700 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469aea8>
2014-05-08 15:12:12-0700 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469aea8>
2014-05-08 15:12:12-0700 [TFTP (UDP)] Datagram received from ('172.30.255.101', 1296): <RRQDatagram(filename=/grubx64.efi, mode=octet, options={'blksize': '512'})>
2014-05-08 15:12:12-0700 [TFTP (UDP)] Datagram received from ('172.30.255.101', 1296): <RRQDatagram(filename=/grubx64.efi, mode=octet, options={'blksize': '512'})>
2014-05-08 15:12:12-0700 [-] RemoteOriginReadSession starting on 56400
2014-05-08 15:12:12-0700 [-] RemoteOriginReadSession starting on 56400
2014-05-08 15:12:12-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a440>
2014-05-08 15:12:12-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a440>
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] (UDP Port 41252 Closed)
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] (UDP Port 41252 Closed)
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a098>
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a098>
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2014-05-08 15:12:12-0700 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2014-05-08 15:12:12-0700 [-] (UDP Port 56400 Closed)
2014-05-08 15:12:12-0700 [-] (UDP Port 56400 Closed)
2014-05-08 15:12:12-0700 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a440>
2014-05-08 15:12:12-0700 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fbbe469a440>
2014-05-08 15:12:13-0700 [-] Unhandled Error
 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/twisted/application/app.py", line 392, in startReactor
     self.config, oldstdout, oldstderr, self.profiler, reactor)
   File "/usr/lib/python2.7/dist-packages/twisted/application/app.py", line 313, in runReactorWithLogging
     reactor.run()
   File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1192, in run
     self.mainLoop()
   File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1201, in mainLoop
     self.runUntilCurrent()
 --- <exception caught here> ---
   File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 824, in runUntilCurrent
     call.func(*call.args, **call.kw)
   File "/usr/lib/python2.7/dist-packages/tftp/util.py", line 80, in _call_and_schedule
     self.callable(*self.callable_args, **self.callable_kwargs)
   File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 254, in write
     return self.socket.send(datagram)
 exceptions.AttributeError: 'Port' object has no attribute 'socket'

2014-05-08 15:12:13-0700 [-] Logged OOPS id OOPS-4ad4c1419556eb88cc72311fd54f737b: AttributeError: 'Port' object has no attribute 'socket'

Nodes and controller are on the same untagged subnet but there is an lldp'd link between the bladeserver's onboard xgb switches and the controller's connected xgb Arista.

root@pre-maas-ctrl:/var/log/maas/oops/2014-05-08# dpkg -l '*maas*' | cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================================-=============================-============-===============================================================================
ii maas 1.5+bzr2252-0ubuntu1 all MAAS server all-in-one metapackage
ii maas-cli 1.5+bzr2252-0ubuntu1 all MAAS command line API tool
ii maas-cluster-controller 1.5+bzr2252-0ubuntu1 all MAAS server cluster controller
ii maas-common 1.5+bzr2252-0ubuntu1 all MAAS server common files
ii maas-dhcp 1.5+bzr2252-0ubuntu1 all MAAS DHCP server
ii maas-dns 1.5+bzr2252-0ubuntu1 all MAAS DNS server
ii maas-region-controller 1.5+bzr2252-0ubuntu1 all MAAS server complete region controller
ii maas-region-controller-min 1.5+bzr2252-0ubuntu1 all MAAS Server minimum region controller
ii python-django-maas 1.5+bzr2252-0ubuntu1 all MAAS server Django web framework
ii python-maas-client 1.5+bzr2252-0ubuntu1 all MAAS python API client
ii python-maas-provisioningserver 1.5+bzr2252-0ubuntu1 all MAAS server provisioning libraries

Repro:
This is a pretty standard initial configuration afaict, following the provided instructions. I notice there are no grub.cfg-* anywhere, only the grub.cfg template. Could that be why none of the nodes are doing anything once they're in the grub shell?

root@pre-maas-ctrl:~# cat /var/lib/maas/boot-resources/current/grub/grub.cfg

# MAAS GRUB2 pre-loader configuration file

# Load based on MAC address first.
configfile (pxe)/grub/grub.cfg-${net_default_mac}

# Failed to load based on MAC address.
# Load amd64 by default, UEFI only supported by 64-bit
configfile (pxe)/grub/grub.cfg-default-amd64
root@pre-maas-ctrl:~# ls -l /var/lib/maas/boot-resources/current/grub/
total 4
-rw-r--r-- 1 root root 270 May 6 18:23 grub.cfg

root@pre-maas-ctrl:~# locate grub.cfg
/boot/grub/grub.cfg
/usr/share/doc/grub-common/examples/grub.cfg
/var/lib/maas/boot-resources/snapshot-20140506-172255/grub/grub.cfg

Controller VM is connected to unrouted internal private network and external lab, which is not used by MaaS. Nodes are only connected to the private n/w. Controller is managing tftp, dhcp and dns and ip helper pointed to its private IP.

Nodes are configured for 'Default Ubuntu Release' Trusty Tahr. Boot images:

4 trusty amd64 generic commissioning release May 6, 2014, 6:23 p.m.
7 trusty amd64 generic install release May 6, 2014, 6:23 p.m.
3 trusty amd64 generic xinstall release May 6, 2014, 6:23 p.m.
5 trusty i386 generic commissioning release May 6, 2014, 6:23 p.m.
12 trusty i386 generic install release May 6, 2014, 6:23 p.m.
9 trusty i386 generic xinstall release May 6, 2014, 6:23 p.m.
6 precise amd64 generic commissioning release May 6, 2014, 6:23 p.m.
11 precise amd64 generic install release May 6, 2014, 6:23 p.m.
10 precise amd64 generic xinstall release May 6, 2014, 6:23 p.m.
2 precise i386 generic commissioning release May 6, 2014, 6:23 p.m.
8 precise i386 generic install release May 6, 2014, 6:23 p.m.
1 precise i386 generic xinstall release May 6, 2014, 6:23 p.m.

[Julian Edwards (julian-edwards)]

Looks related to the recent UEFI work, passing over to Andres.

[Blake Rouse (blake-rouse)]

Looks like grub is having an issue with either your network card or a miss routing of the network. Would it be possible to try and boot the machine using PXELINUX, instead of UEFI. If that works then we can confirm that it is a grubnetx64.efi issue, and can link it to that package.

[Launchpad Janitor (janitor)]

[Expired for MAAS because there has been no activity for 60 days.]

[Raphaël Badin (rvb)]

The stacktrace is there because MAAS' tftp implementation doesn't know about this error (it seems it's something new). But the original problem is that the TFTP request contains an option that isn't supported by the server. We need to figure out what this option is (a full tcpdump would be helpful here).

[Gavin Panella (allenap)]

In absence of a traffic dump, try applying e8.patch to the cluster:

    cd /usr/share/pyshared/tftp
    sudo patch -2 < .../e8.patch
    sudo restart maas-clusterd

This should give us more information about the error being sent from the remote system.

[Gavin Panella (allenap)]

>     cd /usr/share/pyshared/tftp
>     sudo patch -2 < .../e8.patch
>     sudo restart maas-clusterd

That should read:

    cd /usr/share/pyshared/tftp
    sudo patch -p2 < .../e8.patch
    sudo restart maas-clusterd

[Patrick Mullaney (pm-mullaney)]

attached log showing original error and then a boot attempt with the patch applied(starting at 2015-02-03 17:40:17).

[Raphaël Badin (rvb)]

It seems the patch worked as expected:

2015-02-03 17:40:17+0000 [TFTP (UDP)] Datagram received from ('10.61.163.200', 1161): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'tsize': '0', 'blksize': '1468'})>
2015-02-03 17:40:17+0000 [TFTP (UDP)] Datagram received from ('10.61.163.200', 1161): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'tsize': '0', 'blksize': '1468'})>
2015-02-03 17:40:17+0000 [-] RemoteOriginReadSession starting on 51426
2015-02-03 17:40:17+0000 [-] RemoteOriginReadSession starting on 51426
2015-02-03 17:40:17+0000 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fc4416f45f0>
2015-02-03 17:40:17+0000 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fc4416f45f0>
2015-02-03 17:40:17+0000 [RemoteOriginReadSession (UDP)] Got error: <tftp.datagram.ERRORDatagram object at 0x7fc4416e8a90>
2015-02-03 17:40:17+0000 [RemoteOriginReadSession (UDP)] Got error: <tftp.datagram.ERRORDatagram object at 0x7fc4416e8a90>

First attempt to transfer bootx64.efi, fails with the "Terminate transfer due to option negotiation" error (no stacktrace thanks to the patch)

2015-02-03 17:40:17+0000 [-] (UDP Port 51426 Closed)
2015-02-03 17:40:17+0000 [-] (UDP Port 51426 Closed)
2015-02-03 17:40:17+0000 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fc4416f45f0>
2015-02-03 17:40:17+0000 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fc4416f45f0>
2015-02-03 17:40:17+0000 [TFTP (UDP)] Datagram received from ('10.61.163.200', 1162): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'blksize': '1468'})>
2015-02-03 17:40:17+0000 [TFTP (UDP)] Datagram received from ('10.61.163.200', 1162): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'blksize': '1468'})>
2015-02-03 17:40:17+0000 [-] RemoteOriginReadSession starting on 34911
2015-02-03 17:40:17+0000 [-] RemoteOriginReadSession starting on 34911
2015-02-03 17:40:17+0000 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fc4416f0440>
2015-02-03 17:40:17+0000 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7fc4416f0440>
2015-02-03 17:40:17+0000 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2015-02-03 17:40:17+0000 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful

Second attempt to transfer the same file (bootx64.efi); this time the transfer is successful (note how the original request didn't contain the 'tsize' this time, probably because the value was '0' the first time, and that's why the first request failed)

[Gavin Panella (allenap)]

It's a shame we're not getting any details from the remote system as to why it doesn't like the negotiated options. Anyway, this seems to work (right?) so I'll get it landed.

[Gavin Panella (allenap)]

Filed upstream as https://github.com/shylent/python-tx-tftp/issues/21.

(I can't set this as the bug URL for the python-tx-tftp task.)

[Gavin Panella (allenap)]

A fix has landed upstream (https://github.com/shylent/python-tx-tftp). Can we update the Ubuntu package now?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Add error code 8 to python-tx-tftp." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Chirayu Patel (chirayup)]

I have the exact same issue when the controller is a VMWare ESX VM. Has this been fixed yet?

[Chirayu Patel (chirayup)]

I do not understand how some files are transferred and pxeliunux file fails

2015-06-08 22:33:31-0700 [TFTP (UDP)] Datagram received from ('192.168.2.100', 1436): <RRQDatagram(filename=bootx64.efi, mode=octet, options={'blksize': '1468'})>
2015-06-08 22:33:31-0700 [-] RemoteOriginReadSession starting on 34727
2015-06-08 22:33:31-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7f0677601e18>
2015-06-08 22:33:32-0700 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2015-06-08 22:33:32-0700 [-] (UDP Port 34727 Closed)
2015-06-08 22:33:32-0700 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7f0677601e18>
2015-06-08 22:33:33-0700 [TFTP (UDP)] Datagram received from ('192.168.2.100', 1437): <RRQDatagram(filename=/grubx64.efi, mode=octet, options={'blksize': '512'})>
2015-06-08 22:33:33-0700 [-] RemoteOriginReadSession starting on 44836
2015-06-08 22:33:33-0700 [-] Starting protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7f0676dafd40>
2015-06-08 22:33:33-0700 [RemoteOriginReadSession (UDP)] (UDP Port 44490 Closed)
2015-06-08 22:33:33-0700 [RemoteOriginReadSession (UDP)] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7f06775ee908>
2015-06-08 22:33:34-0700 [RemoteOriginReadSession (UDP)] Final ACK received, transfer successful
2015-06-08 22:33:34-0700 [-] (UDP Port 44836 Closed)
2015-06-08 22:33:34-0700 [-] Stopping protocol <tftp.bootstrap.RemoteOriginReadSession instance at 0x7f0676dafd40>
2015-06-08 22:33:34-0700 [-] Unhandled Error
        Traceback (most recent call last):
          File "/usr/lib/python2.7/dist-packages/twisted/application/app.py", line 392, in startReactor
            self.config, oldstdout, oldstderr, self.profiler, reactor)
          File "/usr/lib/python2.7/dist-packages/twisted/application/app.py", line 313, in runReactorWithLogging
            reactor.run()
          File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1192, in run
            self.mainLoop()
          File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1201, in mainLoop
            self.runUntilCurrent()
        --- <exception caught here> ---
          File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 824, in runUntilCurrent
            call.func(*call.args, **call.kw)
          File "/usr/lib/python2.7/dist-packages/tftp/util.py", line 80, in _call_and_schedule
            self.callable(*self.callable_args, **self.callable_kwargs)
          File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 254, in write
            return self.socket.send(datagram)
        exceptions.AttributeError: 'Port' object has no attribute 'socket'

Jun 8 22:34:17 maas-poc maas.lease_upload_service: [INFO] Uploading 1 DHCP leases to region controller.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-tx-tftp - 0.1~bzr38-0ubuntu4

---------------
python-tx-tftp (0.1~bzr38-0ubuntu4) wily; urgency=medium

  * debian/patches/05_lp1317705.patch: Regonise error code 8, which is
    used to terminate a transfer due to option negotiation.
    See RFC 2347, "TFTP Option Extension". (LP: #1317705)

 -- Andres Rodriguez <email address hidden> Mon, 22 Jun 2015 12:33:26 -0400

[Chris J Arges (arges)]

Hello Jason, or anyone else affected,

Accepted python-tx-tftp into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-tx-tftp/0.1~bzr38-0ubuntu4~15.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Chris J Arges (arges)]

Hello Jason, or anyone else affected,

Accepted python-tx-tftp into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/python-tx-tftp/0.1~bzr38-0ubuntu4~14.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Andres Rodriguez (andreserl)]

This has been tested and verified. It works as expected. Marking it verification-done

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-tx-tftp - 0.1~bzr38-0ubuntu4~15.04.1

---------------
python-tx-tftp (0.1~bzr38-0ubuntu4~15.04.1) vivid-proposed; urgency=medium

  * debian/patches/05_lp1317705.patch: Regonise error code 8, which is
    used to terminate a transfer due to option negotiation.
    See RFC 2347, "TFTP Option Extension". (LP: #1317705)

 -- Andres Rodriguez <email address hidden> Mon, 22 Jun 2015 12:33:26 -0400

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for python-tx-tftp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Paul Gear (paulgear)]

@brian-murray, it appears this was not released into trusty-updates as mentioned above:

root@myserver:~$ apt-cache policy python-txtftp
python-txtftp:
  Installed: 0.1~bzr38-0ubuntu4~14.04.1
  Candidate: 0.1~bzr38-0ubuntu4~14.04.1
  Version table:
 *** 0.1~bzr38-0ubuntu4~14.04.1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     0.1~bzr38-0ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

I've installed it from -proposed and confirmed that it fixes the oops on one system.

[Brian Murray (brian-murray)]

@paulgear - it wasn't released because of the other bug, LP: #1476175, which still needed verification at the time I made my comment.

[Launchpad Janitor (janitor)]

This bug was fixed in the package python-tx-tftp - 0.1~bzr38-0ubuntu4~14.04.1

---------------
python-tx-tftp (0.1~bzr38-0ubuntu4~14.04.1) trusty-proposed; urgency=medium

  * debian/patches/05_lp1317705.patch: Regonise error code 8, which is
    used to terminate a transfer due to option negotiation.
    See RFC 2347, "TFTP Option Extension". (LP: #1317705)

python-tx-tftp (0.1~bzr38-0ubuntu3) utopic; urgency=medium

  * debian/patches/04-implement-rollover.patch: Resets the block number
    counter back to 0 after it reaches 2^16. (LP: #1476175)

 -- Andres Rodriguez <email address hidden> Mon, 22 Jun 2015 12:33:26 -0400