System image boots but fails to start essential shepherd services

System image boots but fails to start essential shepherd services

[Richard Sent]

Hi Guix!

I'm trying to generate a system image for an Arm SBC, flash the image to
an SD card, and run Guix on that SD card. The image does boot with the
help of an onboard UEFI bootloader, but Shepherd fails to start any
services.

I generated my image with this command:

--8<---------------cut here---------------start------------->8---
guix system image -L . rsent/machines/lan/caustic.scm --system=aarch64-linux
--8<---------------cut here---------------end--------------->8---

This is a minified version of the contents of caustic.scm:

--8<---------------cut here---------------start------------->8---
(define-public caustic-system
  (operating-system
    ;; lan-minimal-system provides a few additional services on top of %desktop-services
    (inherit lan-minimal-system)
    (kernel (customize-linux #:name "linux-libre-arm64-generic-guix"
                             #:linux linux-libre-arm64-generic
                             ;; Enable QEMU support. Realistically this won't
                             ;; be emulating anything, but enable it anyway
                             ;; because lan-minimal-system uses QEMU and
                             ;; won't boot without it due to the
                             ;; file-system/proc/sys/fs/binfmt_misc shepherd
                             ;; requirement.
                             #:configs '("CONFIG_BINFMT_MISC=m")))
    (initrd-modules '()) ;Not needed with arm64-generic. Most of
                         ;%default-initrd-modules are built in.
    (file-systems (cons*
                   (file-system
                     (mount-point "/boot/efi")
                     (device (file-system-label "boot"))
                     (type "vfat"))
                   (file-system
                     (device (file-system-label root-label))
                     (mount-point "/")
                     (type "ext4"))
                   %base-file-systems))))

(define caustic-image-type
  (image-type
   (name 'caustic-efi)
   (constructor (lambda (os)
                  (image
                   (inherit efi-disk-image)
                   (operating-system os)
                   (platform aarch64-linux)
                   (volatile-root? #f))))))

(define caustic-efi-image
  (image
   (inherit
    (os+platform->image caustic-system aarch64-linux
                        #:type caustic-image-type))
   (name 'caustic-efi-image)))

caustic-efi-image
--8<---------------cut here---------------end--------------->8---

I see many messages printed to the console like this (the specific file
being executed changes, but otherwise it's the same).

--8<---------------cut here---------------start------------->8---
[   15.009930] shepherd[1]: exec of "/gnu/store/zbsi8bm1vx2c2kpl7jrygdhylgvh6ny3-inetutils-2.3/libexec/syslogd" failed: Too many levels of symbolic links
--8<---------------cut here---------------end--------------->8---

Before eventually Shepherd gives up:

--8<---------------cut here---------------start------------->8---
[   46.107131] shepherd[1]: The following services could not be started in the background: guix-daemon ssh-daemon avahi-daemon ntpd NetworkManager xorg-server
 wpa-supplicant upower-daemon pam term-console elogind dbus-system nscd syslogd console-font-tty6 console-fon                                                
[   46.107629] t-tty5 console-font-tty4 console-font-tty3 console-font-tty2 console-font-tty1.
--8<---------------cut here---------------end--------------->8---

Has anyone encountered this issue before? What could be causing this?

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

Re: System image boots but fails to start essential shepherd services

[Richard Sent]

I figured out my issue. It was a result of inheriting
qemu-binfmt-service-type from lan-minimal-system. The problem occurs
when qemu-binfmt is used with a target platform matching the target
system. In my case, qemu-binfmt-service-type was emulating the aarch64
platform which also matched my target system.

The issue is recorded at https://issues.guix.gnu.org/61986. IMO, a
pseudo-bricked generation is a hefty price to pay for an oversight like
this! :)

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.