TrinitronX /storage/.profile can be created and used with LE for interactive shell config. If you want to export the variables to the system environment on boot this should be achievable from /storage/.config/autostart.sh.
Thanks for that tip! Bookmarking this for later! 
Maybe an alternative option: Use the http_proxy / https_proxy environment variables in the system shell profile.
Usually, I'd try creating a drop-in .conf file /etc/profile.d/, with the contents:
export http_proxy=http://username:password@proxy-ip:port
export https_proxy=$http_proxyNote that the lowercase variant of these variables seems to be the most widely accepted across most CLI tools & programming/scripting languages.
However, it's not easily possible to create a file in the read-only filesystem on LibreELEC, and we can't simply remount it read-write since root / is squashfs. Alternatives would be to try a bind mount, or unpacking the /flash/SYSTEM squashfs image on another system, editing the file, and repackaging it. Maybe someone knows an easier way?
To provide more context (for posterity & Google Search reasons), the following information might be helpful for providing more of the engineering details & context for why `gpu_mem is no longer as useful for the Raspberry Pi 4 as it was for previous RPi models:
Setting gpu_mem sets the amount of memory assigned to the VideoCore VPU (Vector Processing Unit). That is responsible for codecs, camera, legacy framebuffer, and the firmware GLES driver on Pi0-3. This region has to be in the bottom 1G of RAM.
On Pi4 the V3D block has an IOMMU, so it can access all of memory, and Linux deals with the allocation out of ARM memory. And when using either DRM/KMS driver (which is default on Pi4), the display buffers come out of the CMA (Contiguous Memory Allocator) heap. Again the CMA heap has to be in the bottom 1G of RAM.
Setting gpu_mem to insane figures gains nothing on a Pi4. Setting the combined value of gpu_mem and CMA to a value greater than 1G (minus a bit) will result in a system that won't boot.
It's all in the docs - https://www.raspberrypi.org/documentati ... /memory.md (ack that this has already been linked to)
Source: Raspberry Pi 4 8GB GPU Memory Split - 6by9's post
... throw away any thoughts on it being even remotely similar to an Intel/Nvidia etc GPU.
The term GPU in OUR case refers to the vector/scaler CPU, the Quad CPU's, the 3D HW blocks, the ISP, the display HW blocks, CODEC blocks etc. Everything that isn't ARM.
The vector/scaler CPU (Its a twin core) can access the first 1GB of RAM, but really don't need that much memory. It controls the rest of the HW blocks - the ones that are not controlled by the ARM. So on older PI's almost all the HW blocks are controlled by the FIRMWARE running on the vector/scaler units. With the Pi4, the 3D is now controlled by the ARM - the so called FKMS driver. However the firmware still controls the display. In KMS, the ARM also handles the display, and with libcamera, the ISP as well is controlled by the ARM. As each of these HW blocks control is moved to the ARM over time, the vector/scaler units require less RAM, so the gpu_memory split can be lower.
A minimal headless system only needs about 16MB of RAM allocated to the 'gpu' - even on the older devices, because you are not using the 3D, is ISP etc.
Source: Raspberry Pi 4 8GB GPU Memory Split - jamesh's post
Hopefully this is helpful to surface this information for those interested.
Someone correct me if i am wrong tho.
While the usual VTY console may not be easily available, it is still possible to use the kernel serial console. This is possible with many embedded platforms such as Raspberry Pi supporting serial connection over the UART pins. To do this, just configure the kernel commandline options with the serial device name, rate, and optionally the data bits, parity, and stop bit settings:
boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 console=ttyAMA0,115200n8 console=tty0In the above example on a Raspberry Pi 2B with OpenElec, the device /dev/ttyAMA0 is attached to the BCM GPIO pins: 14 & 15 (physical pin header pin numbers: 8 & 10). It's possible to set multiple outputs as in this example. The kernel commandline options tell the kernel to output boot messages to both /dev/ttyAMA0 and /dev/tty0. Omitting the usual quiet option turns off silent boot so kernel boot messages will be shown.
For Raspberry Pi specifically, we also need to turn on the UART in config.txt:
# enable_uart - Requests that the kernel creates a serial console, accessible
# using GPIOs 14 and 15 (pins 8 and 10 on the 40-pin header)
enable_uart=1Finally, to get a tty on /dev/ttyAMA0, the init system needs to start an instance of getty on this serial device. However, the absence of the getty busybox binary on OpenElec / LibreElec presents a problem. We need to enable this during busybox build by changing busybox's target configuration to have CONFIG_GETTY=y - see target config here LibreELEC.tv/busybox-target.conf at master · LibreELEC/LibreELEC.tv · GitHub
To have this automatically started by SystemD, you'll need to add the SystemD unit (and enable it) so getty gets started on boot. It looks like both OpenElec and LibreElec removed the getty.target as well as the [email protected] template. So, we will need to place these files back into the root filesystem again. Upstream SystemD has a double-templated version of [email protected] here, which can be used as a starting point. When placing this into the filesystem, remove the {% if ... %} ... {% endif %} sections, because these are Jinja2 template instructions used by SystemD's Meson build system. We want to make sure the resulting SystemD template service has no Jinja2 instructions, so it conforms to the usual SystemD unit syntax. Note that the .in suffix denotes that this file is a build-time template, in this case using Jinja2 syntax for use with Meson. To place it back into the file system, remove all Jinja2 syntax and edit as if you were rendering the Jinja2 template by hand, then place it in one of the SystemD unit directories with filename: [email protected]. It may help to double check the resulting SystemD unit file syntax is valid with: systemd-analyze verify /path/to/[email protected]
The one thing I'm not sure about here is the KillMode=process option, which according to the Jinja2 template is only enabled if SystemD logind is used. Maybe someone more familiar with LibreElec system internals can clarify whether this is needed on this OS?
Because the version of getty used is from busybox, the supported command line arguments may be slightly different. Adapt the typical (a)getty options into busybox's supported getty command options to workaround that. You can either use udev rules or a fixed device instead of a SystemD unit template (the units ending in @.service are templates). In the [Install] section, you can probably install it to multi-user.target, or try leaving it at getty.target so long as that one is copied into the root filesystem and enabled too.
If you choose to use a /etc/udev/rules.d drop-in, make sure to tag it systemd and pass the device name for the SystemD template into systemd-escape, to avoid any issues with converting special characters into a valid SystemD unit + instance name.
For example:
KERNEL=="ttyACM[0-9]*", SUBSYSTEM=="tty", TAG+="systemd", PROGRAM="/usr/bin/systemd-escape -p [email protected] $env{DEVNAME}", ENV{SYSTEMD_WANTS}+="%c"This example udev rule will be used by systemd-udevd to start an instance of the [email protected] template for each device matching pattern: /dev/ttyACM[0-9]*. Alternatively, if you know that only a single serial TTY device will ever be connected to the system, you can simply convert the SystemD unit template into a static non-templated unit file, and replace the template variables (e.g. %i, %I) with the static device name: ACM0. Then just enable that SystemD unit so it will start on boot.
Hopefully this helps those looking to get some form of serial console access working with LibreElec on these embedded platforms such as Raspberry Pi. For more help on how to actually connect with and use a serial console, see "Raspberry Pi Hacks" by Ruth Suehle, Tom Callaway, specifically the section titled: "Hack 16. Add a USB Serial Console". (Hint: Use GNU screen, minicom, picocom, PuTTY, or similar tools)