Hi Ian,
Thanks for trying this out. Ian Eure <[email protected]> writes: > Hi Rutherther, > > Rutherther <[email protected]> writes: > >> This release, system artefacts are available not only for >> x86_64, but >> also for AArch64! This is because AArch64 is also one of the >> primary >> architectures. Since this is the first release with AArch64 >> system >> artefacts, it's especially important for us to get feedback on >> those. >> They should boot even on physical hardware that has UEFI and a >> display. >> >> (snip) >> >> • Guix System installer >> >> >> https://files.ditigal.xyz/guix-release-1.5.0rc1-ruther/guix-system-install-1.5.0rc1.aarch64-linux.iso >> > > Tried this out on my ARM ThinkPad (T14s Gen 6 Snapdragon), and it > successfully boots to GRUB, but GRUB can’t load the installer. > Selecting the installer option in GRUB clears the display > momentarily (only the GRUB menu, the Guix background remains), > then the menu redraws, and the machine hangs. The keyboard isn’t > responsive, I can’t select either entry in the GRUB menu, drop to > the CLI, etc. Okay, I think there are two possibilities: 1. GRUB was unable to boot the Linux. 2. The Linux is in the initrd, unable to mount the root and unable to redraw the screen. I have never seen (1) and cannot really imagine the circumstances for that nor why there would be no error, but I have seen (2) during debugging, so based on that I would go for that one. Specifically, the Linux Libre kernel configuration that Guix has for AArch64, does not have as many modules built-in as x86_64 one. See <https://codeberg.org/guix/guix/issues/4883>. Then we had to add couple of modules here <https://codeberg.org/guix/guix/src/branch/master/gnu/system/install.scm#L528>, as part of the initrd. Still, it is missing any modules for framebuffer, no one yet investaged what are needed exactly. So even in a VM, the screen is blank during boot. It only draws after the initrd boots the full system. > > Linux support for this machine is still incomplete and buggy, but > I think it should be able to boot the kernel and have a working > framebuffer console. I was able to install mainline Ubuntu on it, > though they’re still carrying some hardware-specific patches that > haven’t landed upstream. > > Tested by dd’ing the image onto a USB mass storage device, > specifically a microSD card in a USB-A mSD adapter. Possible that > putting the ISO on a thumb drive is at fault here, though this > type of setup generally works for me. I see Ventoy has some > aarch64 support, I’ll try booting it with that next to see if it > makes a difference. That sounds alright. Supporting USB mass storage is definitely something we should have and tried to have, specifically if you look at the modules added, these should be the xhci ones for USB 3 and ehci for USB 2. It might be good to try both 2 and 3 if you can. Also I would suggest trying just a 'simple' USB flash drive rather than a microSD adapter. Although in the end I think they should need the same drivers as they're pretty much the same from view of the computer, it would be nice to rule out this could be a problem. And if it was, we could again add the needed modules to the initrd-modules. If you ever managed to boot Guix System on it with the default linux-libre kernel, we could take the modules from the booted Guix System, through `lsmod`. In case you had more time on your hands and willingness to experiment, you could try finding out the modules for both the framebuffer support and for what you need for boot. What one might come up with is booting other working distros and checking the modules at their side. Unfortunately it's not as easy, because other distros usually have the modules built-in. So you won't find them in `lsmod`. To build the image, you can either `./pre-inst-env guix system image -t iso9660 ./gnu/system/install.scm --system=aarch64-linux`, or use the release artifacts generation. There you can choose to not use (current-guix) so that you don't have to evaluate for couple of minutes every time. Or you can change this locally, <https://codeberg.org/guix/guix/src/branch/master/gnu/system/install.scm#L345> replacing `(current-guix)` here with `guix`. This is okay for testing boot. For completeness, to generate it as part of the release artifacts, you would do GUIX_USE_SNAPSHOT_PACKAGE=yes SUPPORTED_SYSTEMS=aarch64-linux \ ./pre-inst-env guix build --derivations -m \ ./etc/teams/release/artifacts-manifest.scm Then pick out the iso drv and guix build that. The GUIX_USE_SNAPSHOT_PACKAGE ensures you use currently existing guix package so that you do not have to compile guix yourself. You might do that on top of master or version-1.5.0, it doesn't matter as long as you do not want to reproduce anything, just test the boot. Rutherther > > Happy to test/troubleshoot further, but I’m not sure what would be > helpful. > > -- Ian
