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?
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.
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:
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/)?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?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.Sorry for all those questions, but I’m curious to learn and hope someone can help!
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.
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!
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?
Hi,
Did you managed to get a functionnal Lomiri distro by any chance?
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.
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.
Please check manajro wiki page of amlogiv tv boxes. One of the contributor and documented hours to build own dtb.
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
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.
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.
Actually that guide on the wiki is wrong. You need to run some parser first but you need the kernel sources for that.
This guide works but the question is how to efficiently get the ARM patched kernel sources and then use those.
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.
Yeah, it’s weird. I don’t have such issues, maybe the zfs thing could be the issue.
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.
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!
The image building process only uses pre-built packages.
But you can add your own pre-built package with the -i <package file> argument. You just need to comment out the kernel line from the pinephone profile while doing it, so it does not conflict with your custom package.
Ok, so I think the ZFS issue is related to bind mounts, but I got around that by building in tmpfs, which also doesn’t work.
But the reason it doesn’t work is /var/cache/manjaro-arm-tools/ is assumed to exist. Which is the root of both $PKGDIR and $IMGDIR. I moved those to /tmp, and it breaks the build because they don’t exist in /tmp.
So, I added this, after the conf file is loaded in functions.sh, and I can now build in tmpfs:
#import conf file
source /etc/manjaro-arm-tools/manjaro-arm-tools.conf
# PKGDIR & IMGDIR may not exist if they were changed by configuration, make sure they do.
mkdir -p ${PKGDIR}
mkdir -p ${IMGDIR}
I would like to submit a patch for this. Whats the process? I have an account on the manjaro gitlab but it doesn’t seem possible to make PR’s (at least for me).
There is one outstanding issue I notice though, and that is the bind mount is not cleaned up at the end of the build.
> tmpfs on /tmp/build/var/lib/manjaro-arm-tools/img/rootfs_aarch64/var/cache/pacman/pkg type tmpfs (rw,nosuid,nodev,relatime,size=50331648k,nr_inodes=2097152,inode64)
is left behind which is evident in the build when it goes:
-> Removing rootfs_aarch64
+ rm -rf /tmp/build/var/lib/manjaro-arm-tools/img/rootfs_aarch64
rm: cannot remove '/tmp/build/var/lib/manjaro-arm-tools/img/rootfs_aarch64/var/cache/pacman/pkg': Device or resource busy
So I would fix that before making the PR.