Re: more than one target service shehperd-root / possible scheme records terribleness
Ricardo Wurmus writes: > The issue here is likely that operating-system-services returns all > services, including those that are added by the operating system > machinery. Yes. I ran into this myself the other day. The solution seems to be to use "operating-system-user-services" in place of "operating-system-services" (see gnu/system.scm:263). This is certainly non-intuitive though. -- Simon South si...@simonsouth.net
Re: Who has had success installing a Guix system on arm?
Jesse Gibbons writes: > Has anyone in this mailing list successfully used the Guix system on > an armhf or aarch64 computer? Yes; I'm currently running up-to-date versions of Guix System on a ROCK64 and a Pinebook Pro, both AArch64 systems from PINE64 (https://pine64.org/). I wrote at the time about my experience getting the ROCK64 up and running, including a sample operating-system definition: https://lists.gnu.org/archive/html/help-guix/2020-04/msg00153.html This is still essentially current, except there is no need for the ridiculous dance involving moving a jumper around; turns out U-Boot offers a command that makes it easy to start up from one device but finish booting from another. As others have noted, AArch64 support in Guix is generally quite good now, but a certain amount of patience is required. -- Simon South si...@simonsouth.net
Re: Specifying dependencies among package outputs?
Tobias Geerinckx-Rice writes: > Sound good? Yep, that feels like a natural division. Thanks again, and thanks also for the notes on "propagated-inputs". Onwards and upwards. -- Simon South si...@simonsouth.net
Re: Specifying dependencies among package outputs?
ooner than I did. Even so I think it might be good to add a brief section to the manual that addresses directly how "dependencies" are managed by Guix, since I doubt I'll be the last person who arrives with a traditional package-management mindset and is confused about how Guix handles things. > How would you consider Knot more complex or problematic? Knot seemed to be unique in that its distribution contains the source code for both its executables and the libraries on which they depend, all of which are meant to be built together in a single run. That didn't strike me as unusual at first but searching through gnu/packages, I found plenty of packages whose associated libraries were distributed in a completely separate source distribution and thus were naturally built as a separate package, which made clear the dependency between them. Not finding any obvious examples of packages dependent on their own outputs made me start to think this was perhaps actually very uncommon and not supported by Guix for this reason---though now I understand I didn't find anything because stating this kind of dependency is generally unnecessary, so I was basically searching for something that doesn't exist. [0] https://guix.gnu.org/manual/en/html_node/package-Reference.html#package-Reference [1] https://guix.gnu.org/manual/en/html_node/Derivations.html#Derivations -- Simon South si...@simonsouth.net
Specifying dependencies among package outputs?
Am I right in thinking there is no way to specify dependencies among the outputs of a single package? To specify that a package's "out" output depends on its "lib" output, for instance. I ask because the Knot package (in gnu/package/dns.scm) builds a number of logically distinct targets---daemon, libraries, administrative utilities, general-purpose utilities, and documentation---and it would be nice to separate at least some of these into individual outputs, in part because we could then specify only the libraries as a dependency of Knot Resolver. However, Knot's daemon and utilities have the same dependency on its own libraries, so pulling those into a separate "lib" output would be liable to break everything else. I've searched and can't find an example of this being done, nor can I find any mention of it in the documentation. So I assume it's simply not possible, and you would need to define an entirely separate package that builds from the same source code---right? -- Simon South si...@simonsouth.net
Re: Installing gcc debugging symbols?
Simon South writes: > I could edit gnu/packages/gcc.scm to set the "stripped?" variable to > false... Of course if you're willing to make this change, you can just as easily remove the "hidden-package" wrapper around gcc 4.7's package definition and then install the debug symbols in the usual manner, i.e. with ./pre-inst-env guix install gcc@7.5:debug At least, I assume this is going to work. Still, I wonder if there is a more "official" method that involves less hackery. -- Simon South si...@simonsouth.net
Installing gcc debugging symbols?
Is there a way to install debugging information for gcc, as one can for glibc and other packages? I'm trying to test a change to Knot 3.0.0 and have found that gcc takes forever to finish linking (and usually crashes from running out of memory) when building the package using "guix build knot". Meanwhile, if I build the source "manually", from within "guix environment --pure knot", everything works fine. I'd like to diagnose this but connecting to the running gcc instance using gdb doesn't reveal much without gcc's debugging information available. I've tried "guix install gcc-toolchain@7.5:debug" but that installs debugging information for only glibc. I could edit gnu/packages/gcc.scm to set the "stripped?" variable to false and rebuild gcc so its debugging symbols are preserved, but then it's not clear how to install them. It seems I can build and install gcc itself with guix package --install-from-expression='(@ (gnu packages gcc) gcc-7)' but what I really want is guix package --install-from-expression='(@ (gnu packages gcc) (list gcc-7 "debug"))' This fails with a syntax error, however, and I see the documentation for "guix package" says Note that this option installs the first output of the specified package, which may be insufficient when needing a specific output of a multiple-output package. Is there a trick to making this work? -- Simon South si...@simonsouth.net
Re: Building installation image for ROCK64
Vagrant Cascadian writes: > With your current layout, parts of the bootloader may be written to the > same offsets as files in your first partition... Yes, my mistake. Thanks for pointing that out. > You really want to have the loader1 (start sector 64, 2.5MB size) and > loader2 (start sector 16384, 4MB size) partitions... I'm not sure how literally you meant this to be interpreted, but after a bit of experimentation it seems the most sensible arrangement for now is just to have a single partition starting at sector 32,768 for the root filesystem. This is because - If real partitions are created for the bootloader stages and the trusted firmware, U-Boot will fail to start the OS (with "Unrecognized filesystem type") when it scans for bootable partitions. (It probably ought to just skip over partitions without a recognizable filesystem, but it doesn't seem to behave that way.) - It seems Guix System does not yet support having /boot on a separate partition and will fail at startup if the store isn't available on the same filesystem as extlinux.conf. Consequently reserving 112 MB for a separate boot partition accomplishes nothing. At least this way the root filesystem is safe from being overwritten by the bootloader, and as Guix's support for multiple partitions improves over time it'll be possible to more closely follow Rockchip's conventions. > It would be nice to eventually be able to create installer images for > aarch64/armhf... Yes, absolutely. In the meantime just making available a minimal-but-complete image for writing to a microSD card would be a big help to people looking to get started quickly with Guix on the ROCK64. -- Simon South si...@simonsouth.net
Re: Building installation image for ROCK64
Vagrant,
Thanks to help from you, Pierre Langlois and a few others on IRC I've
had Guix System running on my ROCK64 for a while now. I thought I'd
follow up with the configuration I used and some notes in case it's
helpful to someone else down the road:
I started with an existing GNU/Linux distribution (Armbian Bionic,
though almost any should work fine) installed on my ROCK64's internal
eMMC module, to which I added Guix using the installer script linked
from chapter 2 of the Guix manual.
>From there, log in to the ROCK64 as the superuser. Using fdisk, prepare
a microSD card (/dev/mmcblk0) with a GPT partition table and a single
partition beginning at sector 2,048. Format the partition
(/dev/mmcblk0p1) as ext4, then mount it at /mnt.
Create /mnt/etc and write a configuration file like the one below
(perhaps changing the timezone and locale and adding a user account) to
/mnt/etc/config.scm.
Then, making sure the Guix build daemon is running, have Guix populate
the microSD card with
guix system init /mnt/etc/config.scm /mnt
Once this completes the card will contain a bootable Guix System
image. Power off the ROCK64, place a jumper over the pins behind the
power LED to disable the eMMC clock, and power on the machine again. It
should boot from the card into Guix System.
>From there, the OS can be installed to the eMMC module through a
complicated dance: Using another computer connected to the ROCK64 via
its serial interface, hit Enter during startup to reach the U-Boot
prompt, then carefully (!) remove the jumper from the ROCK64 to
re-enable its eMMC module and enter "boot" to finish booting into
Guix. Edit /etc/config.scm to replace "/dev/mmcblk0" with "/dev/mmcblk1"
(the eMMC module), then repeat the steps above (making the same
substitution) to prepare the module and install a fresh copy of the OS.
The configuration file below is fairly minimal but adds a DHCP client
and OpenSSH server to the base services so the ROCK64 can be accessed
easily once it's connected to a network.
Importantly, it also adds an NTP service to set the date and time at
startup. The ROCK64 has no RTC battery and defaults to 1 January 2016 as
the date at each boot, which causes "guix pull" to fail with an
SSL-certificate error until the clock is set properly. (Note OpenNTPD
itself ocassionally fails to set the clock and it may be necessary to
run "sudo herd restart ntpd" manually after booting.)
Thanks again to you and everyone else who helped me reach this point.
--
(use-modules (gnu)
(gnu bootloader u-boot)
(gnu system nss))
(use-package-modules certs linux ntp)
(use-service-modules networking ssh)
(operating-system
(host-name "rock64")
(timezone "America/Toronto")
(locale "en_CA.utf8")
(bootloader (bootloader-configuration
(bootloader u-boot-rock64-rk3328-bootloader)
(target "/dev/mmcblk0")))
(initrd-modules '())
(kernel linux-libre-arm64-generic)
(kernel-arguments '("console=ttyS2,150"))
(file-systems
(cons* (file-system
(mount-point "/")
(device "/dev/mmcblk0p1")
(type "ext4"))
%base-file-systems))
(packages (append (list nss-certs) %base-packages))
(services (append (list (service dhcp-client-service-type)
(service openntpd-service-type
(openntpd-configuration
(allow-large-adjustment? #t)))
(service openssh-service-type))
%base-services)))
--
Simon South
si...@simonsouth.net
Re: Building installation image for ROCK64
Pierre Langlois writes: > You probably noticed this takes a *long* time to run, making it quite > tedious to test changes (I believe this is being worked on though). > > In the meanwhile, what you can do instead is setup the SD card > manually... Thanks, this should be a BIG help. It takes around three hours and twenty minutes to build a new image on the ROCK64 itself which, as you say, slows down testing considerably. (I assume the main reason is that KVM support is explicitly disabled for aarch64 in gnu/system/vm.scm, but that's a separate issue.) > It was quite some back-and-forth to figure out what was needed. What I > did was to boot a different distro, I think it was Arch at the time, and > look at the dmesg output to see what drivers were loading that I didn't > see with guix. This sounds like a good plan. Thanks very much for the tips, Pierre. I'll give them all a shot and report the results. -- Simon South si...@simonsouth.net
Re: Building installation image for ROCK64
Vagrant Cascadian writes: > This might avoid playing whack-a-mole with arbitrarily complex sets of > drivers: > >(kernel linux-libre-arm64-generic) >(initrd-modules '()) Thanks, Vagrant. That definitely got me further, though the machine still fails to finish booting: [0.243248] rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator [0.243264] rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22 [0.243279] rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv on device rockchip-pinctrl [0.243291] reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread GC Warning: Couldn't read /proc/stat Welcome, this is GNU's early boot Guile. Use '--repl' for an initrd REPL. loading kernel modules... loading '/gnu/store/6a4pyi34awj0jkd6ipl39dylj675ipxm-system/boot'... ERROR: In procedure open-file: In procedure open-file: No such file or directory: "/var/run/utmpx" Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. GNU Guile 2.2.6 Copyright (C) 1995-2019 Free Software Foundation, Inc. I assume the missing file is the actual reason for the failure and whatever's going on with the voltage-regulator drivers is unimportant for now. Any chance something in the output above rings a bell? I'll start diagnosing from here---it's probably time to write a real "operating-system" definition for this machine and see what a newly generated image contains. -- Simon South si...@simonsouth.net
Building installation image for ROCK64
Has anyone successfully built an installation image for a PINE64 ROCK64
ARM SBC?
There's a definition for it in gnu/system/install.scm, but building the
image with
guix system disk-image --system=aarch64-linux \
-e "(@ (gnu system install) rock64-installation-os)"
and writing it to a microSD card fails to boot completely as the root
filesystem can't be mounted:
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.
loading kernel modules...
waiting for partition '416bf41b-f6b1-2062-6e00-1979416bf41b' to appear...
waiting for partition '416bf41b-f6b1-2062-6e00-1979416bf41b' to appear...
(...)
waiting for partition '416bf41b-f6b1-2062-6e00-1979416bf41b' to appear...
ERROR: In procedure scm-error:
failed to resolve partition "416bf41b-f6b1-2062-6e00-1979416bf41b"
(I've checked and the GUID above does match the root partition.) I
understand this often means a necessary kernel module is missing from
initrd, but rebuilding the image using the definition below (mostly
copied from install.scm) that explicitly includes the Rockchip MMC
driver produces the same non-functioning result.
Do you know the magic incantation necessary to produce a bootable image
for the ROCK64?
Alternatively, how might I proceed in diagnosing the issue here?
(use-modules (gnu system install)
(gnu system linux-initrd)
(gnu bootloader)
(gnu bootloader u-boot)
(gnu packages linux))
(operating-system
(inherit installation-os)
(bootloader (bootloader-configuration
(bootloader u-boot-rock64-rk3328-bootloader)
(target "/dev/mmcblk0")))
(kernel linux-libre)
(kernel-arguments
(cons "console=ttyS2"
(operating-system-user-kernel-arguments installation-os)))
(initrd-modules (append '("dw_mmc" "dw_mmc-rockchip") %base-initrd-modules)))
--
Simon South
si...@simonsouth.net
