CoreMP135 Debian image

aradke

Hi,

We've just started testing the new CoreMP135 and it is a very nice little unit.

We are running in to a few issues with the current image (M5_CoreMP135_debian12_20240507.7z)

It seems that they primarily are a result of incorrect permissions set during the image creation:

$ ls -aln /
total 52
drwxr-xr-x  17    0    0 4096 May 13 14:48 .
drwxr-xr-x  17    0    0 4096 May 13 14:48 ..
lrwxrwxrwx   1 1000 1000    7 Sep  1  2023 bin -> usr/bin
drwxr-xr-x   3 1000 1000 4096 Jul 15  2023 boot
drwxr-xr-x  14    0    0 3920 May 16 10:40 dev
drwxr-xr-x  87    0    0 4096 May 16 10:40 etc
drwxr-xr-x   3 1000 1000 4096 May 13 15:04 home
lrwxrwxrwx   1    0    0    7 May  7 17:21 lib -> usr/lib
drwxr-xr-x   2 1000 1000 4096 Sep  1  2023 media
drwxr-xr-x   2 1000 1000 4096 Sep  1  2023 mnt
drwxr-xr-x   3 1000 1000 4096 May 13 16:23 opt
dr-xr-xr-x 155    0    0    0 May 16 10:39 proc
drwx------   5    0 1000 4096 May 14 10:42 root
drwxr-xr-x  22    0    0  680 May 16 11:05 run
lrwxrwxrwx   1 1000 1000    8 Sep  1  2023 sbin -> usr/sbin
drwxr-xr-x   2 1000 1000 4096 Sep  1  2023 srv
dr-xr-xr-x  12    0    0    0 May 16 10:39 sys
drwxrwxrwt   9    0    0 4096 May 16 10:40 tmp
drwxr-xr-x  11 1000 1000 4096 Sep  1  2023 usr
drwxr-xr-x  12 1000 1000 4096 May 13 15:31 var

Many files within /etc are also owned by UID 1000 and things, like setting the time zone, fail in weird ways due to permission errors until file ownerships are fixed.

Is it possible to get documentation on how to create a Debian image ourselves? This would allow us to fix this but also to create an image with the base packages we need already installed. It would also allow testing the mainline kernel as support becomes available for the STM32.

It would be nice to have a list of all the things that are customised for the CoreMP135, such as the screen, RTC, etc.

ajb2k3

I’ve been working on it for a few weeks but could fix the issue and had home life issues. I’m looking for information on the specific port but it’s been a struggle

flypeek

https://docs.m5stack.com/en/core/M5CoreMP135
1.Watch the final instructional film(development framework)
2.use putty login as root

aradke

@flypeek Thanks for the reply.

Unfortunately this is just for setting up the development environment.

What we would like to do is create our own Debian 12 image. We'd also like to be able to test different kernel versions as we have found a device that doesn't work with the existing kernel but has been fixed in more recent ones.

aradke

@ajb2k3 Are you building a new Debian image or working on a fix for the permissions?

flypeek

A command prompt starting with "$" indicates that the current user is in the normal user state, while a command prompt starting with "#" indicates that the user is in the super user (root) state.

The administrator account with the highest authority in the Linux system is root, also known as the superuser account. There are no restrictions on the use of this account. Administrators can make various changes to the system as long as they obtain this account, such as formatting and Mount the hard drive, add or delete user accounts, change various system services, update the system, etc.

How did you get into the terminal?

ajb2k3

@aradke trying to write documentation on how to do stuff with the CoreMP135 there are 2 ways, directly or via SSH

aradke

@flypeek Please note that the issue is that files and folders are owned by UID 1000 not UID 0.

You are asking about a completely different thing. Whether I access the command prompt by the console or SSH won't change the fact that file permissions and ownerships are incorrect. Whether I am logged in as root, or an unprivileged user, or as a user that has used sudo / su to elevate to root privileges isn't relevant to incorrect permissions.

An example is that timedatectl won't function properly because certain files under /etc are not owned by root. Correcting the permissions is possible and it fixes it, but the entire OS image has files all over the place owned by UID 1000. At this point it would be more reasonable to recreate the image than to try to check every file.

aradke

@ajb2k3 Thanks. :-)

Probably not a help in this case as we're wanting to fix or recreate the base Debian 12 image.

The file system ownerships being incorrect is the first big hurdle. But we also have a couple of USB devices that need a newer Linux kernel and would like to be able to create test images with newer kernels if possible.

ajb2k3

Ok I will work on the image side next and see if I can solve a few things. I know SUDO isn’t installed but yet referance is made to it.

ajb2k3

The source is located here but I'm going crosseyed from looking through it.
I can see how to set the file and directory permissions but not where they are set.
It looks to be a build root version of archlinux

aradke

@ajb2k3 sudo isn't included on a minimal Debian installation. It's usually the very first things that we install so that the rest of the system can be fully configured by Ansible.

aradke

@ajb2k3 if you are building the base filesystem inside a chroot environment then you should be able to install packages as normal via apt.

The permissions from the original source should be fine, and apt will make sure any further permissions are also correct. Going back to fix already damaged permissions would be difficult and it would be very easy to miss something.

ajb2k3

@aradke said in CoreMP135 Debian image:

The permissions from the original source should be fine, and apt will make sure any further permissions are also correct. Going back to fix already damaged permissions would be difficult and it would be very easy to miss something.

That's why I spent last night going through the source so I could find where these are set. I could not find the config for the directory like /etc.

Ah it's the host system that set the file permissions.

When the image was generated it wasn't compiled under root so directorys weren't set as root but to the permissions of the host.
The image need to be re generated as root.

aradke

@ajb2k3 :-)

When creating Linux container templates the same issue can arise. If you do any part of it as a non-root account the file and directory ownerships will all end up being the same as the UID you are currently working with instead of as root, etc.

Sometimes things will appear to function okay for a while but if a directory is meant to be owned by a non-root account, such as www-data, then anything using it will completely fail.

Is there any chance you'll be able to document the procedure for creating the image? It would be very, very good to be able to create customised ones and to test different kernels.

Thanks

ajb2k3

@aradke that’s what I’m doing at the moment. I am taking to the programmer about how to build the image

prima

I am currently writing an Ansible playbook to automate the customization of my device, and some things like setting the time zone don't work for the reason described above. Hopefully this can get fixed soon.

I am also working on the LCD screen, as I would prefer to use Python rather than the proposed C environment.

ajb2k3

@prima well currently I'm trying to get the code to compile following the online instructions but they dont work

ajb2k3

Ah ha I got it to compile, the instructions are wrong.
You need to run

make BR2_EXTERNAL=../CoreMP135_buildroot-external-st/ m5stack_coremp135_515_defconfig
make -j4

To get it to compile.
I'm Using a CM4Stack so its slow going.
The issue turns out to be a typo in the line. The guide says /Core135_ but the command is actually CoreMP135

prima

On a side note and not sure this is a related issue, but I can't seem to shut down the device cleanly. I have tried: shutdown, poweroff, halt and the device always reboots instead of shutting down.