Problems making a bootable aarch64-linux system image

Problems making a bootable aarch64-linux system image

[Ian Eure]

Hi folks,

I’m trying to get Guix System running in a QEMU VM on Apple ARM64 
hardware[1].  This has been much more challenging than I expected, 
and I haven’t been able to get it working at all.  I’m completely 
stuck and could use some advice and/or a working configuration I 
can hack on.

I’ve tried multiple paths to get this working, including building 
both installer and system images on arm64 and amd64 hardware.  My 
current approach is to make a bootable qcow2 system image using 
Guix as a foreign package manager on top of Debian running in a VM 
on the ARM hardware.  This is my image definition: 
https://paste.debian.net/1342063/

It’s buildable with:

  guix time-machine 
  --commit=96cd163c14e68c66c6a4cf0b18261fc454f8c1ba -- system 
  image vakum.scm

(Commits beyond 96cd163c14e68c66c6a4cf0b18261fc454f8c1ba fail, 
because guix tests are currently broken on aarch64-linux; see 
#75205)

This produces an image which boots to GRUB, but fails to boot the 
system.  It seems that the framebuffer console is initialized, 
since I see the QEMU window resize, but then I get a blinking 
cursor in the upper-left and nothing else.

Does anyone have pointers/advice/working configs for this I can 
hack on?  Any help would be greatly appreciated.

Thanks,

  -- Ian

[1]: My work requires everyone to use a Mac, unfortunately.

Re: Problems making a bootable aarch64-linux system image

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Ian Eure <ian@retrospec.tv> writes:

> I’ve tried multiple paths to get this working, including building both
> installer and system images on arm64 and amd64 hardware.  My current
> approach is to make a bootable qcow2 system image using Guix as a
> foreign package manager on top of Debian running in a VM on the ARM
> hardware.  This is my image definition:
> https://paste.debian.net/1342063/
>
> It’s buildable with:
>
>  guix time-machine   --commit=96cd163c14e68c66c6a4cf0b18261fc454f8c1ba
>  -- system   image vakum.scm
>
> (Commits beyond 96cd163c14e68c66c6a4cf0b18261fc454f8c1ba fail, because
> guix tests are currently broken on aarch64-linux; see #75205)
>
> This produces an image which boots to GRUB, but fails to boot the
> system.  It seems that the framebuffer console is initialized, since I
> see the QEMU window resize, but then I get a blinking cursor in the
> upper-left and nothing else.
>
> Does anyone have pointers/advice/working configs for this I can hack
> on?  Any help would be greatly appreciated.

Do you get any output if you remove quiet from the kernel arguments? You
can do this from grub or alter your system configuration
kernel-arguments.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Problems making a bootable aarch64-linux system image

[Ian Eure]

Hi Christopher,

On Thu, Jan 2, 2025, at 9:03 AM, Christopher Baines wrote:
> Ian Eure <ian@retrospec.tv> writes:
>
>> I’ve tried multiple paths to get this working, including building both
>> installer and system images on arm64 and amd64 hardware.  My current
>> approach is to make a bootable qcow2 system image using Guix as a
>> foreign package manager on top of Debian running in a VM on the ARM
>> hardware.  This is my image definition:
>> https://paste.debian.net/1342063/
>>
>> It’s buildable with:
>>
>>  guix time-machine   --commit=96cd163c14e68c66c6a4cf0b18261fc454f8c1ba
>>  -- system   image vakum.scm
>>
>> (Commits beyond 96cd163c14e68c66c6a4cf0b18261fc454f8c1ba fail, because
>> guix tests are currently broken on aarch64-linux; see #75205)
>>
>> This produces an image which boots to GRUB, but fails to boot the
>> system.  It seems that the framebuffer console is initialized, since I
>> see the QEMU window resize, but then I get a blinking cursor in the
>> upper-left and nothing else.
>>
>> Does anyone have pointers/advice/working configs for this I can hack
>> on?  Any help would be greatly appreciated.
>
> Do you get any output if you remove quiet from the kernel arguments? You
> can do this from grub or alter your system configuration
> kernel-arguments.
>

No, it behaves exactly the same.  Blinking cursor, no output, no progress.

But thank you for mentioning this!  I've been wondering why my machine was more verbose than a fresh install, and it's because I was clobbering %default-kernel-arguments, so this was indirectly helpful.

Thanks,
  -- Ian

Re: Problems making a bootable aarch64-linux system image

[Ian Eure]

Hi all,

I was able to get this working by looking at another user's VM config.scm.  I believe my error is that I provided a list of packages, instead of appending to %base-packages.

  -- Ian

On Thu, Jan 2, 2025, at 5:28 PM, Ian Eure wrote:
> Hi Christopher,
>
> On Thu, Jan 2, 2025, at 9:03 AM, Christopher Baines wrote:
>> Ian Eure <ian@retrospec.tv> writes:
>>
>>> I’ve tried multiple paths to get this working, including building both
>>> installer and system images on arm64 and amd64 hardware.  My current
>>> approach is to make a bootable qcow2 system image using Guix as a
>>> foreign package manager on top of Debian running in a VM on the ARM
>>> hardware.  This is my image definition:
>>> https://paste.debian.net/1342063/
>>>
>>> It’s buildable with:
>>>
>>>  guix time-machine   --commit=96cd163c14e68c66c6a4cf0b18261fc454f8c1ba
>>>  -- system   image vakum.scm
>>>
>>> (Commits beyond 96cd163c14e68c66c6a4cf0b18261fc454f8c1ba fail, because
>>> guix tests are currently broken on aarch64-linux; see #75205)
>>>
>>> This produces an image which boots to GRUB, but fails to boot the
>>> system.  It seems that the framebuffer console is initialized, since I
>>> see the QEMU window resize, but then I get a blinking cursor in the
>>> upper-left and nothing else.
>>>
>>> Does anyone have pointers/advice/working configs for this I can hack
>>> on?  Any help would be greatly appreciated.
>>
>> Do you get any output if you remove quiet from the kernel arguments? You
>> can do this from grub or alter your system configuration
>> kernel-arguments.
>>
>
> No, it behaves exactly the same.  Blinking cursor, no output, no progress.
>
> But thank you for mentioning this!  I've been wondering why my machine 
> was more verbose than a fresh install, and it's because I was 
> clobbering %default-kernel-arguments, so this was indirectly helpful.
>
> Thanks,
>   -- Ian