Sudo no available

problems with default libreelec samba config

Be aware that if you are using Windows 10 Fall update you must type the path in the address into the file explorer address bar. Like \\192.168.1.87.

For reasons I don't understand I don't have to type the url on one of my updated Windows machines.

However, there should be no need to share any files that are not included in the default samba. You can get to the config files and userdata with it.

I agree with the argument that sudo is not needed when you are root. However I doubt very much that ssh root@IP really logs you in as a fully qualified root. I tried to modify config files and found out that many directories are write protected (rwx,rwx,r_x). Root should be able to edit such files or at least change the previleges with chmod. Nothing of that works.

Could somebody please give an advice how to handle this problem?

ssh root@libreelec will log you in as full root user. But keep in mind that the root filesystem (/etc, /usr ...) is read-only and can't be changed. /flash is mounted read-only as well, but you can modify the files there after you remount it rw.

so long,

Hias

Quote from warp2

I agree with the argument that sudo is not needed when you are root. However I doubt very much that ssh root@IP really logs you in as a fully qualified root. I tried to modify config files and found out that many directories are write protected (rwx,rwx,r_x). Root should be able to edit such files or at least change the previleges with chmod. Nothing of that works.

Could somebody please give an advice how to handle this problem?

The root filesystem is a (compressed) squashfs file system and therefore must be readonly. Even root cannot modify any files there. If you want to make changes there, you need to re-create the squashfs and perform an update of the box. Modifying the squashfs can only be performed on a linux system. Best is probably to just build the whole system on your own, then you can modify everything according to your needs.

Thank you both of you for coming back so fast.

I can‘t say that I like this rock solid write protection. After all there will be quite a number of installations that will be modified in one way or the other.

If we are talking about safety I think any Linux system can be set up to a safety level much higher than what a media player should have. The bad point of this solution is, that it forces the user to give up the the standard ....

Besides that I really like LE - an excellent product - well done.

If you don't like the approach LibreELEC is using better use some other media center distribution like OSMC - that one is Debian/Raspbian based and you can use sudo, apt-get etc

so long,

Hias

One option is to use overlay like here: Alternative to Kodi packages: Modroot - Development - LibreELEC Forum

Thank you guys for coming with the great solution for this question. Thanks a lot.

HiassofT

I think it is obvious that I like LE more than OSMC et al.

I hope you do not take it as an insult that I do not see any reason why the file system has to be bullet proof. This SW just plays audio and video - it is not a banking app.

Most of all I thought this SW was meant to be open to the community for fine tuning and experiments or did I get the wrong message?

I agree the present approach improves stability. But this thread as well as several others show that users are discussing ways to bypass safety arrangements. From my point of view safety is a very personal matter. If a user refuses to change the default PW ....

Back to LE: My suggestion is to give full root access plus access to the file system to allow the user an easy setup. Then give him a script that sets system to either "safety" or "open" and asks for a new and long PW.

Quote from warp2

Most of all I thought this SW was meant to be open to the community for fine tuning and experiments or did I get the wrong message?

It is open: source code is available and you can change it to your needs.

Btw: I did make whole system RW few years back. And it was very, very easy. Only few lines of code changed.

Quote from vpeter

Btw: I did make whole system RW few years back. And it was very, very easy. Only few lines of code changed.

I think this lock is not years old, so this might not work on the latest Rev.

I plugged the SDcard into my Linux machine and there I can access the whole file system when I am logged in as root.

warp2 no problem at all and I certainly don't take it as an insult.

Actually some of the design decision of OE/LE, like the read-only rootfs without overlayfs and the lack of a package manager, seemed and partly still seem a bit odd to me.

But I also have to say the approach makes sense for what LE is meant to be - an OS for running kodi that is simple to use for users.

We use kodi's addon system instead of a separate package manager - that makes it simple for users to install additional stuff, as they only have to deal with a single UI (kodi) and we don't need to add a package manager ourselves and write a GUI for it.

The root filesystem being read only also means that chances of users messing up the whole system (whoops, I accidentally replaced/deleted libc) are slim. Users can't easily shoot themselves in the foot and we have less support issues.

OTOH we developers often have to jump through hoops as well to work with the current setup.

Last year I implemented support for optional kernel module packages (mainly used for DVB drivers) and the lack of overlayfs support (Amlogic kernel is too old and doesn't include that) or a package manager (kodi's addon/dependency system is rather simple) meant we had to put a lot of thought into how we could practically use that. It also involved quite a lot of discussion and design decision as the goal was to have something that's both easy to use for users and support for us devs.

As we don't have plans (and the resources) to drastically change the OS design of LE it's best you familiarize yourself with the possibilites how you can adapt LE to your needs:

1. Some things may already be supported and you just need to find/change the right config file
2. You can create an addon if you want some additional programs / services / ... added to LE
3. Using docker is an alternative to #2
4. If none of the above works for you you'll have to adapt the LE source code and build your own version

so long,

Hias

HiassofT

I fully agree that you intend to build a system that a user can not spoil unintentionally. Further it must be a pain to combine existing SW, external stuff, standards etc. and create something that suits everybody. That is simply a mission impossible.

On the other hand Apple shows the advantages of tightly sealed SW on well defined HW. But I have to admit that occasionally I really hate such limits.

I use LE on a Raspberry which requires a setup of the GPIO signals to hook up a DAC, LIRC and a LCD. Depending on the manufacturers of extra HW there is no standard hook up and I have to add a few lines in various config files. In cases like this chances are to spoil the system with a bad workaround. A catch 22......

LE is really great as it is. Documentation and How Tos could help to handle remaining wishes.

Best regards

Warp2

Changing /flash/config.txt entries on RPi is rather safe. Even if you completely mess it up and have a non-booting RPi you can simply put the card in a reader on your PC, clean it up, and have a working setup again.

If you want to hook up a DAC, GPIO IR receiver and an LCD the bigger problem is that most HATs on RPi don't give you easy access to the unused GPIOs (and sometimes you even don't know which ones are unused). So that typically involves soldering some wires to the GPIO pins on the HAT or RPi.

I'm regularly using a sound card (the Cirrus Logic Audio Card) and a GPIO IR receiver on RPi. Fortunately the sound card brings out the unused GPIOs to a separate header block.

A few days ago I tested with a HD44780 compatible VFD, connected via a I2C expander but the I2C pins aren't grought out separately on the card. I added a 40-pin header to the soundcard in my testing setup some time ago (to easily access all signals) so getting to the I2C pins was easy. Without the header I would have needed to solder 5 wires to the pins.

Changing config.txt was easy though, I2C was already enabled via the sound card overlay, otherwise a simple "dtparam=i2c=on" line would have done it.

So, don't be afraid of config.txt, most of the changes are simple and hard to mess up.

so long,

Hias