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
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:
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!
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.
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.
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?
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.
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.
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.
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.
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.
