I don't know how pmbootstrap does it, I always work on the kernel tree directly. Try asking in a Nura chat, they're on IRC.

Sorry i'm a bit dumb how do i say to the command pmbootstrap build to use my dts file ? if it's not in the APKBUILD i dont understand. There is my APKBUILD in case that's useful :

 `# Reference: <https://nura.eco/vendorkernel>
 # Kernel config based on: arch/arm64/configs/(CHANGEME!)
 maintainer=""
 pkgname=linux-realme-rmx3263
 pkgver=4.14.193
 pkgrel=0
 _commit=3e85eafa35a4915079900d50834fb184a05c65db
 pkgdesc="Realme C21Y kernel fork"
 arch="aarch64"
 url="https://kernel.org/"
 license="GPL-2.0-only"
 makedepends="
     bash
     bc
     bison
     devicepkg-dev
     elfutils-dev
     findutils
     flex
     linux-headers
     openssl-dev
     pahole
     perl
     python3
     "
 source="
     $pkgname-$_commit.tar.gz::https://github.com/realme-kernel-opensource/realme_C21Y-AndroidR-kernel-source/archive/$_commit.tar.gz
     config-${pkgname#linux-}.$arch
     "
 builddir="$srcdir/realme_C21Y-AndroidR-kernel-source-$_commit"
 options="
     !check
     !strip
     !tracedeps
     pmb:cross-native
     "
 _outdir="out"

 _carch="arm64"

 # Used internally by pmbootstrap. Don't touch.
 # TODO: Remove once minimum default pmbootstrap version supports
 # kernel packages without '_flavor' and '_config'.
 _config="config-${pkgname#linux-}.$arch"
 _flavor="${pkgname#linux-}"

 prepare() {
     default_prepare
     REPLACE_GCCH=0
     . downstreamkernel_prepare
 }

 build() {
     unset LDFLAGS
     make O="$_outdir" ARCH="$_carch" CC="${CC:-gcc}" \
	     KBUILD_BUILD_VERSION="$((pkgrel + 1 ))"-postmarketOS
 }

 package() {
     downstreamkernel_package "$builddir" "$pkgdir" "$_carch" \
	     "${pkgname#linux-}" "$_outdir"
     make dtbs_install O="$_outdir" ARCH="$_carch" \
	     INSTALL_DTBS_PATH="$pkgdir"/boot/dtbs
 }'

Not the APKBUILD file, that's the .dts file from the error.

Could also be in one of the files that it includes (see #include something.dtsi at the beginning)

How do i define it and include in the build ? I dont see the option in the APKBUILD file.

https://www.kernelconfig.io/CONFIG_GPIO_BRCMSTB?q=gpio-brcmstb&kernelversion=7.3.1&arch=arm64

Just disable that and get the kernel to build. Then try to fix the issues.

The GPIO is probably used for thermals sensors and physical buttons, perhaps some other sensors, so don't be suprised when those don't work.

Also, as Clippy says: Asking in the Nura chats can help, although chats have the risk of questions getting lost. I prefer using threads like here or a forum. It's also easier to search than a chat.

The Device Tree (.dts) references something that is not defined.

Two options:

• Define it
• Comment it out (for now) and continue with the port

Also, gpio-brcmstb.c cannot be compiled. I assume it's a downstream driver. See if the kernel successfully compiles if you disable the option for it in the kernel config, probably has 'BRCMSTB' in it, perhaps something like CONFIG_GPIO_BRCRMSTB (I'm making this up, but should be similar).

You can always try to look for gpio-brcmstb on kernelconfig.io if it is a driver that is upstream. This should give you an explanation what this driver is and what the config option for it is.

You might want to ask in the Matrix room https://matrix.to/#/#porting:postmarketos.org

Thank you for letting me know. I didn't actually see that page before I posted lol. If it needs to be deleted, then so be it. I guess the main purpose of this post would then be to say, that full support for the device IS technically possible.

I don't know if anyone still even uses their ASUS Deb/Flo, but I did already intend to host the packages on a git repository (either on my own server's Gitea Instance, or Github, or both) when I am finished, as I'm working on my own Nura based distribution for my devices anyway.

Gemini's new Argon 4 is actually REALLY amazing. I had been munching away at this for months with Gemini 3 beside me and Gemini Argon 4 got it working in a day.

i'm sorry to report that Nura's current AI policy is so strongly opposed that it might even result in this very lemmy post being deleted: https://docs.nura.eco/policies-and-processes/development/ai-policy.html (though hopefully not - although the mods of this lemmy community are Nura developers, it isn't on their list of community spaces)

see https://github.com/sv1sjp/mi-max2-oxygen-msm8953-nura-drivers#about-ai-assistance-and-contributing-upstream (via this post^[see also my comments here and here for my thoughts on this]) for another device which someone nura-enabled with LLMs and can't/won't try to upstream to Nura. :/

hopefully their policy evolves soon; if not i expect some fork/overlay will eventually emerge for maintaining the sure-to-be-growing set of devices which are only supported thanks to LLM-assisted efforts. until then, i'd recommend doing something like what @sv1sjp@lemmy.world is doing.

Yes, found it eventually, thanks!

I guess you're looking for this

I tried the newest one from the second of October, but it also doesn't boot. I'll try to open a bug at this point I guess.

Those CPUs are x64, but more importantly at the moment I'm trying to install it on a virtual machine on my 1 year old laptop, which is definitely x64 :D

Huh. What is your plan to keep up with future updates and debugging?

As I stated in the post, I developed the drivers and the research with AI, so I published them in my own GitHub repository. An automated script exists so anyone can pretty easily installed these drivers to his Mi Max 2 if he wants to.

Working "on Nura"? You link to github.com

The title is misleading.

You clearly got it working with a Nura, but not "on Nura".

Or am I just unable to find that in the Nura repos anywhere?

@sv1sjp very nice!afaik, u can contribute to nura if and only if ur pmaports/pmbootstrap (if there are any) changes are handwritten. the linux kernel (and many projects that Nura depends on) are ok with ai patches so in pmaports, u can point to ur own fork in the linux kernel and upstream any conf filesgreat work!

Weird, to narrow things down I'd try another installer image and see if it'll boot.

VERY old PCs (AMD Athlon XP old)
(...)
20260925-1250-postmarketOS-edge-os-installer-10-generic-x86_64-lts.img

Could the problem be that you are trying to run 64-bit on 32-bit machines?

You're right that I didn't select it there, but when the no bootable media found showed up I opened up the boot manager and selected the QEMU DVD-ROM, but with no luck. Regardless, now I enabled it, but it still won't boot.

You probably have to enable booting the CD rom in the boot section, this ones gotten me a couple times before.

Your assumptions are right about balena, it should just copy the exact .img blob to the flash drive without modifications.

But also run a lscpu on that old machine and check vulnerabilities, and maybe turn off hyperthreading if you don't want the library users to get hacked.

With a system that is several years old: Just flash it again.

Hello @INeedMana@piefed.zip! I have decided to not use this OS any longer. Since the EFI entry works, I tried it, and it's not what I'm looking for. Thank you for all the help, tho.

1. 2. and 3. is all correct.

I use systemd mode in MX. In pmOS's entries there is no such choice, unless... the 2 dublicate options in the "advanced options" GRUB entry is actually the dual init format specific to MX? Then we can assume this is an incompatibility on MX Linux's part? I guess I tried booting pmOS in both modes, but I don't see any difference. All the later tests bellow were done on the main pmOS GRUB entry, not in the "advanced options".

The strangely named "6969" UUID is real, sda6's UUID is named like that, and I don't know why.

All UIIDs in order:

• EFI
  • 13AA-3B2E
• OTHERS
  • 081de505-7ddd-482a-aff8-9403865510d7
  • 829c2c7a-d475-4692-bc78-d8502ded5d3b and LUKS e1bae6b2-c0b7-47de-bb88-3261cf0c83ba
  • 37e894b4-435c-4156-a923-7cfc27b6705f and LUKS f68c92ec-cade-4686-b467-70f4100c36e0
  • 0ba63eb1-ffa9-466c-ab2a-9b29db2882d2
• PMOS
  • 6969-ACCE
  • 791e8d35-d7ec-46ed-9b53-a70a8beebe14

The photo is exactly all the visible text on screen, and nothing else appears bellow the screen.

There is no initrd in sda6, but there is vmlinuz-lts. In pmbootstrap I choose the Alpine LTS kernel, and I don't know if that's related to vmlinuz-lts's naming.

(hd0,gpt7) did not fix anything regarding the line 249 edit.

The line 242 edit produced, just bellow the rdinit error: Skipping autodetection of RAID arrays. (raid=autodetect will force). I later then reverted this edit and added sda7's UUID to line 249, replacing (hd0,gpt7), and it produces me same RAID array error.