Looks like you figured that out and got the correct version of that second command. (The "&&" is how you'd run more than one command at a time.)
From your serial.log, this is about the only thing that raises my eyebrows:
2018-12-21 03:02:32,666 - Send: M20
2018-12-21 03:02:32,682 - Recv: Begin file list
2018-12-21 03:02:32,698 - Recv: /OLDER/SHORTD~1.GCO
2018-12-21 03:02:32,713 - Recv: /OLDER/CR-10E~1/HUBA3H~1.GCO
2018-12-21 03:02:32,761 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/1/HUBA3H~1.GCO
2018-12-21 03:02:32,790 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/2/EAST_D~1.GCO
2018-12-21 03:02:32,791 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/3/BAIZEH~1.GCO
2018-12-21 03:02:32,806 - Recv: /OLDER/CR-10E~1/47ACB~1.MOD/YAXISW~1/CR-10~1.GCO
2018-12-21 03:02:32,866 - Recv: /OLDER/CR-10~1/HUBA3H~1.GCO
2018-12-21 03:02:32,868 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,869 - Recv: 1380A~1.��
2018-12-21 03:02:32,870 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,872 - Recv: 25282~1.��
2018-12-21 03:02:32,873 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,874 - Recv: 30C02~1.��
2018-12-21 03:02:32,876 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,877 - Recv: 451AC~1.��
2018-12-21 03:02:32,879 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,880 - Recv: 5927D~1.��
2018-12-21 03:02:32,882 - Recv: echo:Cannot open subdir
2018-12-21 03:02:32,883 - Recv: 62CC5~1.��
2018-12-21 03:02:32,884 - Recv: /OLDER/C_FRON~1.GCO
I'm sure others would know more but strange characters in a file list from your printer controller's SD card could suggest either card corruption, wonky firmware or a problem in the serial line. I've suggested before that Marlin may not be happy with Microsoft-style long filenames but others think that it's okay with that.
If this were a classic early-Raspi-firmware-on-a-3B+ situation, then the Pi itself would freeze up and not be responsive to anything, forcing a power boot to return to service. I think you've ruled that out if you've now updated the firmware with that apt-get upgrade.
You "new" cable hopefully has internal metallic shielding or one or two ferrite cores.
Your serial log looks nearly pristine to me. I don't love the temperature responses coming back from your firmware with the question mark at the end; that looks odd to me.
I'm noting that although you're not in Safe Mode, you don't seem to have any additional plugins other than those bundled.
Looks like a problem running one of the bundled plugins:
2018-12-21 03:03:19,169 - octoprint.plugin - ERROR - Error while calling plugin tracking
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/__init__.py", line 230, in call_plugin
result = getattr(plugin, method)(*args, **kwargs)
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/tracking/__init__.py", line 119, in on_event
self._track_printjob_event(event, payload)
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/tracking/__init__.py", line 237, in _track_printjob_event
sha.update(self._settings.get([b"unique_id"]))
TypeError: update() argument 1 must be string or buffer, not None
It did this right after you kicked off the print job. It's the tracking plugin. This has to be the Anonymous Usage Tracking plugin, new with this major version. Here's the bit of code that's throwing the error:
def _track_printjob_event(self, event, payload):
if not self._settings.get_boolean(["events", "printjob"]):
return
sha = hashlib.sha1()
sha.update(payload.get("path"))
sha.update(self._settings.get([b"unique_id"]))
Do me a favor. Run this cat ~/.octoprint/config.yaml | grep unique (copy/paste that into your putty session). You should see a value there.