#archlinux-ports | Logs for 2026-05-02

Back
[00:00:01] -!- bertptrs has quit []
[00:00:43] -!- bertptrs has joined #archlinux-ports
[03:07:43] -!- hcmb_ has joined #archlinux-ports
[03:07:43] -!- hcmb has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
[03:07:43] hcmb_ is now known as hcmb
[06:38:10] -!- Charon77|PC has joined #archlinux-ports
[07:18:25] -!- idealseal_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
[07:23:05] -!- idealseal has joined #archlinux-ports
[08:02:49] -!- yjun123 has quit [Quit: Konversation terminated!]
[08:05:14] -!- yjun123 has joined #archlinux-ports
[08:10:18] -!- linkmauve has parted #archlinux-ports
[08:20:18] -!- yjun123 has quit [Quit: Konversation terminated!]
[08:20:55] -!- linkmauve has joined #archlinux-ports
[08:25:03] -!- yjun123 has joined #archlinux-ports
[08:37:20] -!- filmroellchen has joined #archlinux-ports
[09:16:09] <bertptrs> are there some docs ·on how to get the aarch64 port installed on an rpi5?
[09:26:03] <solskogen|M> Yes-ish. It's all about just partitioning your target device and unpack the tarball into it.
[09:30:05] <solskogen|M> What we miss is some bootstrap images that people just can copy to a sd card or usb device and boot from there. I have a small script ready that creates those images, but we don't have those images published anywhere.
[09:30:14] <bertptrs> I got the tarball just now, let's see
[09:31:10] <bertptrs> is it correct that the tarball does not have a kernel?
[09:38:04] <bertptrs> found this: https://gist.github.com gonna see if that works
[09:38:06] <phrik> Title: Installing Arch Linux aarch64 (drzee.net port) on Raspberry Pi 5 · GitHub (at gist.github.com)
[09:55:33] <solskogen|M> I'm away for the next 24 hours
[09:56:50] <bertptrs> ah it doesn't work because `arch-chroot` obviously won't work
[10:33:43] <abelvesa> solskogen|M: bschnei: has anyone looked into the chance of using pacman-pkg target from kernel tree instead of having PKGBUILD in archlinux ?
[10:34:12] <abelvesa> I have been using that on alarm until now
[10:34:57] <abelvesa> though the dtbs are part of the same package and they are placed under /lib/module/<kernel version/dtbs instead /usr/lib/dtbs
[10:35:43] <abelvesa> I do prefer the /usr/lib/dtbs instead, so maybe this is worth upstreaming in the kernel's PKGBUILD
[11:01:43] -!- anthraxx has quit [Quit: leaving]
[11:06:54] -!- Charon77|PC has quit [Quit: Charon77|PC]
[12:32:45] <bertptrs> haven't figured it out yet. new plan, install alarm, swap mirrors
[12:53:11] -!- dvzrv has quit [Quit: WeeChat 4.8.1]
[12:53:47] -!- dvzrv has joined #archlinux-ports
[14:40:54] <bschnei> bertptrs: I've used the approach outlined here: https://wiki.archlinux.org a couple of times to get things going. It can have some bumps but it does work.
[14:40:56] <phrik> Title: Install Arch Linux from existing Linux - ArchWiki (at wiki.archlinux.org)
[14:42:19] <bschnei> For pi5 specifically I started with the default PiOS image and just added a new partition to the same sd card and installed there
[14:43:34] <bschnei> Migrating from ALARM is also a pretty straightforward approach just remember to reinstall all packages after switching mirrors
[14:46:06] <bertptrs> thanks, something got in between so I haven't made much progress
[14:46:15] <bschnei> abelvesa: I haven't. Can you help me understand the advantages or problems it solves? re: dtbs you make me wonder if we'll need to move them again (ugh). They are versioned with the kernel and/or there could be use cases where people want to install multiple kernels with different dtbs....
[14:46:45] -!- yjun123 has quit [Quit: Konversation terminated!]
[14:46:48] <bertptrs> I have an rpi5 with an nvme so I'll try to 1. get an rpios setup going, then 2. install the arch port to the nvme
[14:47:54] <bschnei> nice! that should work well. just be mindful of /boot. the linux-rpi5 package will attempt to configure it for you only if it doesn't already find existing configuration files
[14:48:25] <bschnei> logic for that is here: https://github.com
[14:48:27] <phrik> Title: linux-rpi5/linux-rpi5.install at main · bschnei/linux-rpi5 · GitHub (at github.com)
[14:50:53] -!- yjun123 has joined #archlinux-ports
[15:20:50] -!- alkersan has joined #archlinux-ports
[15:42:55] -!- yjun123 has quit [Remote host closed the connection]
[15:43:24] -!- yjun123 has joined #archlinux-ports
[15:56:20] -!- drathir_tor has quit [Ping timeout: 265 seconds]
[15:58:03] -!- drathir_tor has joined #archlinux-ports
[16:24:29] <abelvesa> bschnei: actually, thinking some more about the kernel upstream PKGBUILD, I don't think it aligns at all with the guidelines of archlinux PKGBUILD. My understanding is that we need an archlinux specific PKGBUILD that allows adding patches on top, though no actual scenario comes to mind right now. The kernel upstream PKGBUILD doesn't allow that. And none of the other distros seem to be using the
[16:24:35] <abelvesa> kernel upstream packaging target.
[16:24:56] <abelvesa> for example, debian distro doesn't actually use the deb-pkg (or similar)
[16:25:14] <abelvesa> so it doesn't make sense to do that in archlinux either
[16:26:50] <abelvesa> as for path for dtbs, I don't think it makes much sense to keep multiple versions around, since the latest DTB should boot with older kernel, at least in theory. Otherwise it would be an ABI break.
[16:27:42] <abelvesa> so keeping newest dtbs (assuming you only install newer kernels and don't go back) makes perfect sense to me
[16:28:54] <abelvesa> the PKGBUILD from ustream is really useful for easily testing kernels with archlinux, but doesn't make sense to be used in stable packages
[16:29:05] <abelvesa> *from upstream kernel
[16:36:29] <bertptrs> took me most of my saturday but I'm running the port on my rpi5!
[16:37:43] <bertptrs> now I might actually be able to contribute
[16:47:27] <bschnei> nice!!!
[16:48:07] <bschnei> abelvesa: ya if you look at the linux package you'll also note that there are patches. We are building that Arch Linux kernel fork w/ any patches
[16:50:07] <bschnei> ya but what is "latest" dtbs if someone wants to install -rc or whatever versions. I'm not too concerned about it now, but I could see use cases for multiple dtbs. Maybe the answer is as simple as if you are doing that kind of work, you are on your own anyway and shouldn't be using distro packages to manage your kernels/dtbs
[16:56:21] -!- marmis has quit [Quit: Bye!]
[16:59:03] -!- marmis has joined #archlinux-ports
[17:31:49] -!- rennod has quit [Remote host closed the connection]
[17:33:19] -!- rennod has joined #archlinux-ports
[18:41:10] -!- bill-auger has joined #archlinux-ports
[20:15:11] -!- bs86_ has joined #archlinux-ports
[20:16:10] -!- bs86 has quit [Ping timeout: 256 seconds]
[20:16:10] bs86_ is now known as bs86
[21:35:46] -!- heftig has quit [Quit: Bridge terminating on SIGTERM]
[21:35:46] -!- integral|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- tpkessler|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- artafinde|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- anthraxx|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- dvzrv|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- bgyorgy|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- tippfehlr|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- solskogen|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- archmatrix has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- carsme|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- jelle|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- C0rn3j|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:47] -!- antiz|M has quit [Quit: Bridge terminating on SIGTERM]
[21:35:57] -!- archmatrix has joined #archlinux-ports
[21:41:03] -!- heftig-weechat has joined #archlinux-ports
[21:52:49] <phantomas> abelvesa: [latest dtbs should boot older kernel] I wouldn't assume that, nor would it be breaking API. Say for example a new pmic is released, compatible with an older one, but the register aren't mapped the same way. Booting an older kernel could might cause issue as the driver hasn't been adapted yet
[21:54:01] <phantomas> older dtbs should work with newer kernel tho, but the other way around is not necessarily true
[22:10:12] -!- titus_livius has joined #archlinux-ports
[22:10:46] <abelvesa> s/doesn't work newer ABI/doesn't work with newer DTB/
[22:11:48] <abelvesa> phantomas: ideally, DTB should come from OEM and be complete and correct out of the factory, but kernels are updated
[22:15:22] <phantomas> more correct doesn't mean it will work, hence the need to use the one working with your specific version.
[22:16:31] <phantomas> [ideally DTB should come from OEM] yeah, but for that you'd need for OEM to ship upstreamable drivers. I wouldn't hold my breath for that to happen
[22:25:17] <abelvesa> phantomas: either way, switching older DTB shouldn't be needed ...
[22:28:38] <phantomas> If you want to keep several kernel installed, you may need several DTBs version installed as well
[22:34:14] -!- filmroellchen has quit [Quit: filmroellchen]
[22:34:30] <abelvesa> phantomas: yeah, that's what the upstream kernel PKGBUILD does and it forces you to always update the path to the dtb in uki.conf ...
[22:35:06] <abelvesa> phantomas: so I prefer this one instead. And even if you install an older kernel, it will bring its dtbs anyway ...
[22:35:53] <abelvesa> phantomas: the only thing you don't have is multiple version of the dtbs at the same time, but then that applies to modules as well
[22:39:11] <phantomas> I'm not sure I get your latest message, but for module, their path is tied to the kernel version. Doing that with DTBs would be safer while making 0 differences for users with only one kernel installed
[22:40:22] <abelvesa> phantomas: are you saying the modules are still there for older kernels ?
[22:40:48] <abelvesa> phantomas: yest they are tied up to the kernel version, but once you install a new kernel, the old one goes away, doesn't it ?
[22:41:33] <phantomas> Kinda? If you upgrade the package, the previous version is uninstalled. If you have multiple package, only the files for the one being updated are removed
[22:42:12] <abelvesa> phantomas: as for "Doing that with DTBs would be safer while making 0 differences", the mainline kernel PKGBUILD does that already, and I hate it because you have to update the uki.conf (DeviceTree) manually due to kernel version
[22:42:15] <phantomas> If you have linux and linux-lts, you'd have 2 module folders, and (IMO) you should have 2 dtbs folders as well
[22:43:40] <abelvesa> phantomas: that does make sense, yes, but not like the kernel mainline does, which is to install modules into /lib/modules/<kernelversion>/dtb
[22:45:07] <phantomas> Regarding uki.conf, I don't use it, but couldn't you just cp the file from <kernel_versioned/dtb/yourfile> to another place and keep uki.conf stable if that's the issue?
[22:45:18] -!- solskogen|M has joined #archlinux-ports
[22:45:30] -!- heftig has joined #archlinux-ports
[22:45:40] -!- anthraxx|M has joined #archlinux-ports
[22:46:10] -!- C0rn3j|M has joined #archlinux-ports
[22:46:11] <phantomas> In my case I use systemdboot to setup the device-tree on boot, and the plan was to use a hook to copy the correct file to /boot after it has been installed
[22:46:20] -!- bgyorgy|M has joined #archlinux-ports
[22:46:40] -!- dvzrv|M has joined #archlinux-ports
[22:47:10] -!- integral|M has joined #archlinux-ports
[22:48:00] -!- tpkessler|M has joined #archlinux-ports
[22:48:10] -!- artafinde|M has joined #archlinux-ports
[22:48:20] -!- carsme|M has joined #archlinux-ports
[22:48:30] -!- antiz|M has joined #archlinux-ports
[22:49:20] -!- tippfehlr|M has joined #archlinux-ports
[22:49:30] -!- jelle|M has joined #archlinux-ports
[22:54:00] <abelvesa> phantomas: the idea with uki + stubble is to be able to boot same uki on multiple machines and it should be able to pick the right dtb based on hwids
[22:54:49] <abelvesa> phantomas: so in uki.conf you could say: DeviceTreeAuto = machine_a.dtb \n DeviceTreeAuto = machine_b.dtb ... and so on
[22:55:54] <phantomas> Well you can cp multiple files
[22:56:12] <abelvesa> phantomas: so if dtbs are installed by the package into anything that has the kernel version, you need to update the path, for more than one dtb
[22:57:12] <phantomas> Yeah, but if someone doesn't use uki + stubble, or want have multiple kernel, you're basically closing the door to that, or have only one package as a first-class citizen
[22:57:12] <abelvesa> phantomas: ideal approach would've been to have the uki.conf DeviceTree point to relative path to the DTB rather than absolute
[22:57:36] <abelvesa> s/DeviceTree/DeviceTreeAuto//
[22:58:13] <abelvesa> so instead of: DeviceTreeAuto = /lib/modules/7.1.0-rc1/dtb/qcom/x1e80100-dell-xps13-9345.dtb
[22:58:43] <abelvesa> it should've been: DeviceTreeAuto = qcom/x1e80100-dell-xps13-9345.dtb
[22:59:06] <abelvesa> and then it should've figure it out based on the version of the kernel that is being installed as uki
[22:59:22] <phantomas> abelvesa: But you could have /etc/uki/dtbs and just symlink/cp the files you want in there when they are installed
[23:00:00] <abelvesa> so you still need to update the symlinks if the path to them includes the kernel version
[23:00:11] <phantomas> Yes
[23:00:34] <phantomas> As you would need to using another bootloader that need the file to be copied to /boot
[23:01:05] <abelvesa> so you are saying ukify should do that?
[23:01:17] <abelvesa> hm, might not be a bad idea
[23:01:30] <phantomas> Possibly, or that could be a pacman hook that user set-up
[23:01:53] <abelvesa> well, doing it in ukify would solve it for all distros
[23:02:01] <phantomas> True
[23:02:47] <abelvesa> hm, let me give it some thought. Might be worth going that way and then install the dtbs as the PKGBUILD does in the upstream kernel
[23:02:55] <phantomas> But specifically for Arch, my point is that solving a problem for one specific setup shouldn't make it harder for everybody else
[23:03:15] <abelvesa> true
[23:05:16] <abelvesa> then bschnei, maybe you can move the dtbs into /lib/modules/<kernelversion>/dtb, just like the upstream kernel PGKBUILD does:
[23:05:19] <abelvesa> https://git.kernel.org
[23:05:24] <phrik> Title: PKGBUILD « package « scripts - kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org)
[23:38:08] -!- bill-auger has quit [Remote host closed the connection]