[Wiki] How to contribute to Manjaro ARM

ARM General ARM Discussion
21

The theme for GDM is applied correctly :slight_smile: that makes me happy. some succes today!

Summary 
$ sudo pacman -U manjaro-gdm-theme-20201005-1-any.pkg.tar.zst 
loading packages...
resolving dependencies...
looking for conflicting packages...
Packages (1) manjaro-gdm-theme-20201005-1
Total Installed Size:  0.93 MiB
:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                     [######################] 100%
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) checking available disk space                [######################] 100%
:: Processing package changes...
(1/1) installing manjaro-gdm-theme                 [######################] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Manjaro GDM theme install

manjaro-gnome-assets : dependency issues that cannot be solved by me tonight and i’m not that commited.

Summary 
$ sudo pacman -U manjaro-gnome-assets-20201017-1-any.pkg.tar.zst 
loading packages...
resolving dependencies...
warning: cannot resolve "manjaro-gnome-settings", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-gnome-extension-settings", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-arcmenu", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-dash-to-dock", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-appindicator", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-dash-to-panel", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-pop-shell", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-material-shell", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-gsconnect", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-desktop-icons-ng", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-unite", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-shell-extension-gamemode", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "gnome-wallpapers", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-base-skel", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "qgnomeplatform", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "illyria-wallpaper", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-wallpapers-18.0", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "manjaro-gdm-branding", a dependency of "manjaro-gnome-assets"
warning: cannot resolve "nerd-fonts-noto-sans-mono", a dependency of "manjaro-gnome-assets"
:: The following package cannot be upgraded due to unresolvable dependencies:
      manjaro-gnome-assets

:: Do you want to skip the above package for this upgrade? [y/N] n

Manjaro-gnome-extention-settings has no extention files to edit since they are not installed.

Summary 
$ sudo pacman -U manjaro-gnome-extension-settings-20201121-1-any.pkg.tar.zst 
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) manjaro-gnome-extension-settings-20201121-1

Total Installed Size:  0.00 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                                                      [##########################################################] 100%
(1/1) checking package integrity                                                                    [##########################################################] 100%
(1/1) loading package files                                                                         [##########################################################] 100%
(1/1) checking for file conflicts                                                                   [##########################################################] 100%
(1/1) checking available disk space                                                                 [##########################################################] 100%
:: Processing package changes...
(1/1) installing manjaro-gnome-extension-settings                                                   [##########################################################] 100%
Optional dependencies for manjaro-gnome-extension-settings
    manjaro-gnome-settings-20.2
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Compiling Community GSettings XML schema files...
No schema files found: doing nothing.
No schema files found: doing nothing.
No schema files found: doing nothing.

manjaro-gnome- postinstall wil regenerate all locales, killed the install, will try on fresh image tomorow

manjaro-gnome-settings has a file conflict.

Summary 
$ sudo pacman -U manjaro-gnome-settings-20201121-1-any.pkg.tar.zst 
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) manjaro-gnome-settings-20201121-1

Total Installed Size:  0.04 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                                                      [##########################################################] 100%
(1/1) checking package integrity                                                                    [##########################################################] 100%
(1/1) loading package files                                                                         [##########################################################] 100%
(1/1) checking for file conflicts                                                                   [##########################################################] 100%
error: failed to commit transaction (conflicting files)
manjaro-gnome-settings: /etc/skel/.config/mimeapps.list exists in filesystem
Errors occurred, no packages were upgraded.

I’m learning alot about making a working image, thank you for the tips, the tools and patience answering my questions, where would I start to read when i want to know more about profiles, overlay, skel directories and how it all ties together? I’ve been looking at the wiki and assumed the process was roughly similar

Gnome does seem slowish, but running from a sd card. once I am happy enough with my settings (and unable to further adjust because I lack the knowledge/time) I’ll run with it and see how it goes. So far I’m enjoying myself immensely with this :slight_smile:

2 Likes
22

People don’t give sd cards enough credit. Sure, they top out in the 45MB/s range for unbuffered read/write on my RPI4, but their 4k random read speed is upwards of 10+ TIMES the speed of a HDD’s assuming you got a good card. The random read speed is what really affects the feel of a system. Combine that with the fact that you can do cached writes and re-reads of common files in the GB/s range until you fill buffers, and you’ve got a pretty darn good experience. Don’t do 4k video editing on them, sure, or run large databases, or a file server and expect speeds faster than the sd card can read, but for just an OS, web browser, all that jazz, the SD card isn’t slowing you down most likely.

Gnome is just… SLOW on arm. It’s GPU intensive, demands composition, and isn’t light weight compared to plasma and most of the other environments. That’s not to say it’s a fat pig, but arm in the SBC SoC ream is really good at showing you which pig is indeed larger :wink:

1 Like
23

So GDM would be doable.

That’s a lot of package we would have to maintain to get that one package working.

Yeah, again, the extensions would have to be packages we would maintain.

Can you tell what package (if any) contains that file with pacman -Qo /etc/skel/.config/mimeapps.list?

24

It would make the ’ Gnome experience’ look a bit more like the x86 if using gdm.

Then better not make the effort, my assumptions where not correct (besides the GDM theme) and gnome is not performing as wel as other options . So until this improves and there is enough demand there would be no reason to add them.

$ pacman -Qo /etc/skel/.config/mimeapps.list 
error: No package owns /etc/skel/.config/mimeapps.list

check on main machine:

$ pacman -Qo /etc/skel/.config/mimeapps.list                                                                     
/etc/skel/.config/mimeapps.list is owned by manjaro-gnome-settings 20201121-1

so it also depends on a package that would be extra work for no benefit.

25

Hi, thanks for this overview! I’m trying to build an up to date image of Lomiri for the PinePhone and I’m starting to understand more and more of the process. Some things are not clear to me yet, some help would be appreciated:

  • How do I properly install packages that I built with buildarmpkg into the rootfs? A lot of packages for Lomiri depend on each other and I would like to use my updated builds for the build process instead of the outdated ones in the ARM repository that are being pulled automatically as dependencies. I thought the -i option for buildarmpkg would do exactly that, but it seems this only takes packages I have on my machine (in /var/cache/pacman/pkg/)?
  • This makes me wonder about the same question for buildarmimg, will I be actually able to use my manually built packages with -i for building an image in the end or did I misinterpret that option?
  • Apart from manjaro-arm-tools, are there ways of interacting with the build environment/rootfs that I keep reusing with buildarmpkg -k? A couple of times I ran into the problem that after starting a build (Building xyz ...) nothing happened forever (for hours) and I had to manually kill the process (Ctrl+C told me that the user aborted, but buildarmpkg still didn’t finish). After that my build environment (reused with -k) was useless, I kept getting the message pacman is currently in use. So I had to use a new environment which had to pull all the dependencies again, always takes a while.
  • Say I manage to update everything properly and get a working image, how does the process of contributing work? Do I just push my commits/updated PKGBUILDs, then someone looks at them and if it is considered alright, a new package will be built remotely and updated in the repos?
  • Some packages changed their name upstream. What’s the best way to handle that? I changed the downstream name accordingly, but would it have to be marked somewhere what old package this new package replaces? Would the repo name have to be changed?

Sorry for all those questions, but I’m curious to learn and hope someone can help!

26

I will try my best to explain:

When creating an image, you would need to use the -i flag of buildarmimg. It only supports adding 1 local package though.

It’s just a regula rootfs/chroot, so you could chroot into with any of the usual means, as long as you have qemu-user-static installed.

It sounds like you ware in the process of updating the entire Lomiri stack. This should not be done locally with our tools. It’s simply not what they are designed to do. What you would want to do is adding all the packages you build with buildarmpkg to an online repository. You can then add that repository to your buildarmimg command with the -k flag, like buildarmimg -k https://mynewrepo.domain.com/$branch/$repo/$arch/.
That will make buildarmimg use the repo you designated as it’s first source when installing packages.

If you do manage to build and test it all, you would need to somehow submit these new working PKGBUILD’s to us, so we can update our gitlab and have our CI build the images.

Yes. This is done in the PKGBUILD with the replaces=() line. In there you put it’s old package name.
And yes, we will have to change the gitlab repo name to also match the new name.

1 Like
27

Thank you very much, that was very helpful!

I tried that, but it didn’t work. Looking at the source code of the tools (which luckily was much easier to understand than I thought) cleared things up a lot. Seems like the local package needs to be in the same directory where buildarmpkg is run, because if you supply a path (which I did) it gets parsed together with the package name later on which results in a non existent path.

Great, I should have checked that, makes it a lot easier.

Yes, I am trying to update the entire stack (might take a while …). I wasn’t aware of the -k flag, thanks. I’ll try to build my own local repo then with repo-add (just found out about that) and modify buildarmimg to have it copied into the rootfs since I don’t have a domain where I could host a repo.

Thank you for the quick reply!

1 Like
29

Correct. He is not. Helmut seems to have stepped down as a maintainer, so the package probably won’t be updated until someone takes it over. Maybe @Yochanan or @oberon will take over Helmuts old packages?

1 Like
30

Hi,

Did you managed to get a functionnal Lomiri distro by any chance?

31

No the lomiri team got busy with other priorities. We should be able to build it again with the new patches but it will still at the same stage where it was left.

32

I’m trying to compile a dts file for my TV box into a dtb but I’m not sure how exactly to do this from
my x86_64.
I got the linux package and I can compile it for ARM but I’d like a simple way to just compile my dts , make some modifications, compile and test again all the while keeping the patches that are coming from the linux package.
Hopefully I’ve explained this clearly enough.

33

Please check manajro wiki page of amlogiv tv boxes. One of the contributor and documented hours to build own dtb.

34

I am currently in the process of trying to port a new arm target to Manjaro.
Its based on a RK3399 so i started with trying to build a pre-existing image, but it fails.
Specifically, when I run sudo buildarmimg -d rockpro64
The first error i notice is:

(12/16) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k 5.15.0-2-MANJARO-ARM -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.15.0-2-MANJARO-ARM
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [plymouth]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [keyboard]
  -> Running build hook: [fsck]
==> ERROR: file not found: `fsck.zfs'
==> WARNING: No fsck helpers found. fsck will not be run on boot.
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly

There is no ZFS on the target, so it looks like something in my PC setup is leaking into the build.

Followed shortly later by:

==> Finishing image for rockpro64 minimal edition...
  -> Creating partitions...
  -> Copying files to image...
cp: error writing '/var/lib/manjaro-arm-tools/tmp/root/usr/lib/libgo.so.16.0.0': No space left on device
cp: error writing '/var/lib/manjaro-arm-tools/tmp/root/usr/lib/libmagic.so.1.0.0': No space left on device
cp: error writing '/var/lib/manjaro-arm-tools/tmp/root/usr/lib/libnpth.so.0.1.2': No space left on device
cp: error writing '/var/lib/manjaro-arm-tools/tmp/root/usr/lib/liblz4.so.1.9.3': No space left on device
cp: error writing '/var/lib/manjaro-arm-tools/tmp/root/usr/lib/libss.so.2.0': No space left on device
cp: error writing '/var/lib/manjaro-arm-tools/tmp/root/usr/lib/libdl.a': No space left on device

Which repeats for what looks like every possible file. I have 1.5TB of available disk space, and 128GB of ram, so i don’t think its really a “No space left on device” issue, but I can’t work out what could be causing it.

Any ideas?

Full log is on ghostbin dot com / 5bE4C

36

Hi @nl.smart ,
I did read and follow the docs. My target is headless, so all i need to build is minimal images which is what -e defaults to. -v also has a reasonable default for the purpose of my testing to see if i can build an existing target faithfully, before trying to build my new target. The only option i didn’t add was -n and that was because i had already downloaded the rootfs previously. But I did try your suggestion and I get the exact same errors.

log is at https://ghostbin.com/q5SJn

I feel like this may be an incompatibility between the build process and ZFS in some way, but I want to make sure I haven’t screwed up something before digging deeper. I am going to try and format a USB drive as Ext4 and try a build on that, to rule out ZFS peculiarities.

38

I have never seen that zfs thing before, but I haven’t ever run the tools on a zfs based system. Don’t know why it would try to include it in the initramfs though, if you haven’t changed the arm-profile at all.

Regarding the “No space left on device”, what version of the tools are you using?

We increased the size of the .img file in 2.10.3, because I was starting to get similar issues when building images. So if your version is 2.10.2 or below you will likely run into the same issue.

39

Actually that guide on the wiki is wrong. You need to run some parser first but you need the kernel sources for that.

Device Tree - linux-sunxi.org

This guide works but the question is how to efficiently get the ARM patched kernel sources and then use those.

1 Like
40

Hi @Strit, Well I switched to staging branch of Manjaro to pick up 2.10.4.
Sadly that didn’t help, I still get the no space left on device errors with it.
I also tried formatting a USB stick as Ext4 (My whole system is Full ZFS) and pointing manjaro-arm-tools.conf to that, but that didn’t help either, but the error is different.
on the USB Ext4 drive I am getting:

==> Creating package list: [/tmp/build/var/cache/manjaro-arm-tools/img/Manjaro-ARM-minimal-rockpro64-21.11-pkgs.txt]
mv: cannot move '/tmp/build/var/lib/manjaro-arm-tools/img/rootfs_aarch64/var/tmp/pkglist.txt' to '/tmp/build/var/cache/manjaro-arm-tools/img/Manjaro-ARM-minimal-rockpro64-21.11-pkgs.txt': No such file or directory
  -> Cleaning rootfs for unwanted files...
  -> Prune and unmount pkg-cache...
==> no candidate packages found for pruning
umount: /tmp/build/var/lib/manjaro-arm-tools/img/rootfs_aarch64/var/cache/pacman/pkg: not mounted.
==> rockpro64 minimal rootfs complete
==> Finishing image for rockpro64 minimal edition...
  -> Creating partitions...
  -> Copying files to image...
mount: /tmp/build/var/lib/manjaro-arm-tools/tmp/boot: can't read superblock on /dev/loop0p1.
mount: /tmp/build/var/lib/manjaro-arm-tools/tmp/root: can't read superblock on /dev/loop0p2.
  -> Flashing bootloader...
  -> Writing PARTUUIDs...
Boot PARTUUID is ...
Root PARTUUID is ...
  -> Cleaning up image...
umount: /tmp/build/var/lib/manjaro-arm-tools/tmp/root: not mounted.
umount: /tmp/build/var/lib/manjaro-arm-tools/tmp/boot: not mounted.
chmod: cannot access '/tmp/build/var/cache/manjaro-arm-tools/img/Manjaro-ARM-minimal-rockpro64-21.11.img': No such file or directory
  -> Compressing Manjaro-ARM-minimal-rockpro64-21.11.img...
/usr/share/manjaro-arm-tools/lib/functions.sh: line 815: cd: /tmp/build/var/cache/manjaro-arm-tools/img: No such file or directory
Manjaro-ARM-minimal-rockpro64-21.11.img (1/1)
xz: Manjaro-ARM-minimal-rockpro64-21.11.img: No such file or directory
chmod: cannot access '/tmp/build/var/cache/manjaro-arm-tools/img/Manjaro-ARM-minimal-rockpro64-21.11.img.xz': No such file or directory
  -> Removing rootfs_aarch64
==> Time : 7.95 minutes...

/tmp/build is the USB drive mount point.

Looks like I need to get serious. I will clone the latest source for manjaro-arm-tools and try and debug what the issue really is with my system. Once I work out what the actual command/s that fail, I should be able to work out a fix.

41

Yeah, it’s weird. I don’t have such issues, maybe the zfs thing could be the issue.

42

Yeah, I think your right. It could be a file system option thats not enabled, or it could be a tooling issue. I will get to the bottom of it.

43

Hi, I’m interested in building my own Manjaro image for my Pinephone so I can change a kernel config. However I’m a beginner so it’s not clear to me if the process in the OP here will let me do that (it seems like it uses a pre-built kernel?). Any pointers on how to include a custom kernel in the build process explained here are appreciated, thanks in advance!