Sinem

One debugging shortcut that saves a lot of guessing: log what the application thinks the request scheme and host are, on one request, temporarily.

Every discussion of this ends up being an argument about what the app sees, and the app can simply be asked. Print the effective scheme, host and origin at the top of a view, submit one form, read the log, and you know immediately whether the proxy headers are arriving and whether the app is honouring them.

If the port exists and the upload still fails with no serial data received, the usual causes are:

• Something else holding the port. A serial monitor left open, another editor, a logging tool. Only one program can have it. Close everything and retry — this is astonishingly common.
• The board is not in a state to accept a program. Some boards need a button held during upload, or a specific reset sequence, particularly the wireless families. The documentation for your exact board will say; the generic instructions will not.
• A sketch that immediately reconfigures the pins or crashes can make the board unavailable moments after reset. The recovery is the manual bootloader entry above.
• Power. A board drawing more than the port supplies browns out mid-upload. Try a powered hub or a different machine.

The chicken-and-egg case, which is why this is annoying: sometimes the partition is so full that the package manager cannot complete the removal, because it wants to regenerate a boot image and has nowhere to put it.

The way out is to make a little room by hand first, carefully:

• The initial ramdisk images are the largest files there. Removing one belonging to an old kernel — not the running one, not the newest — usually frees enough to let the proper cleanup run.
• Then immediately run the package manager's cleanup, and let it fix the bootloader configuration.

After that, check the bootloader menu is sane before rebooting, and reboot at a time you can get to a console if it goes wrong. On a remote machine with no console access, that is the moment to be genuinely careful.

Your caution is right, and the safe route is to let the package manager remove old kernels rather than deleting files.

First, find out which kernel you are actually running:

uname -r

Never remove that one, and keep at least one other as a fallback. Everything older than those two is a candidate.

Then use the package manager's own cleanup, which knows what belongs to what and updates the bootloader afterwards. On Debian-family systems that is the autoremove operation, which is aware of which kernels are still needed; on others there is an equivalent that keeps a configured number of versions.

The reason to avoid deleting by hand is not that the files are magic — it is that the bootloader configuration still references them afterwards. A machine that boots into a rescue prompt because the entry points at a kernel you deleted is a much worse afternoon than a full partition.