* Re: ARMHF flash image - Put on website under GuixSD
2018-09-10 12:28 ` Ludovic Courtès
@ 2018-09-10 13:47 ` pelzflorian (Florian Pelz)
2018-09-10 15:12 ` Danny Milosavljevic
2018-09-10 15:45 ` Vagrant Cascadian
2 siblings, 0 replies; 6+ messages in thread
From: pelzflorian (Florian Pelz) @ 2018-09-10 13:47 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Mon, Sep 10, 2018 at 02:28:52PM +0200, Ludovic Courtès wrote:
> I agree that it would be nice, but to what extent is this image generic
> to all ARM boards? My understanding is that images are necessarily
> bound to a specific board.
>
Many images, one for each board, is what people are accustomed to for
other distros.
Alternatively reconfiguring an existing system to GuixSD could be
simplified.
Regards,
Florian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARMHF flash image - Put on website under GuixSD
2018-09-10 12:28 ` Ludovic Courtès
2018-09-10 13:47 ` pelzflorian (Florian Pelz)
@ 2018-09-10 15:12 ` Danny Milosavljevic
2018-09-10 15:45 ` Vagrant Cascadian
2 siblings, 0 replies; 6+ messages in thread
From: Danny Milosavljevic @ 2018-09-10 15:12 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]
Hi Ludo,
On Mon, 10 Sep 2018 14:28:52 +0200
ludo@gnu.org (Ludovic Courtès) wrote:
> > Can we put it on the website at https://www.gnu.org/software/guix/download/
> > inside the GuixSD part?
> >
> > I think it would be nice to have something ready-to-go for ARM systems as well,
> > and this would be a good start. Apart from the bootloader, everything should
> > work as-is in there. And the user can either keep the original bootloader
> > on the board or flash a new one after booting GuixSD - either in qemu or
> > on a real machine.
>
> I agree that it would be nice, but to what extent is this image generic
> to all ARM boards? My understanding is that images are necessarily
> bound to a specific board.
Yes, but only because of the bootloader (that's a pretty big "but").
It's possible to change it inside qemu, and in the end there has to be *some*
way for a user to bootstrap the things (usually using the vendor image).
ARM boards are very diverse - some load the bootloader and the root fs from SD card,
some load the bootloader from flash and the root fs from SD card,
some load everything from flash,
some load the bootloader from flash and the root fs from NFS etc.
In the end we can also provide one image per board, but we should use a
block-deduplicating filesystem then - because everything but ~30 kB of each image
will be the same!
>Other considerations include the fact that it’s yet another image to
>build when we make a release, but perhaps the solution is simply to
>improve our automation and build farm availability.
I think if we want to support it it has to be built at least once.
Otherwise we don't know whether it has a chance to work, no? Having
the flash-image isn't really much more work on top of that.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARMHF flash image - Put on website under GuixSD
2018-09-10 12:28 ` Ludovic Courtès
2018-09-10 13:47 ` pelzflorian (Florian Pelz)
2018-09-10 15:12 ` Danny Milosavljevic
@ 2018-09-10 15:45 ` Vagrant Cascadian
2018-09-10 20:54 ` Ludovic Courtès
2 siblings, 1 reply; 6+ messages in thread
From: Vagrant Cascadian @ 2018-09-10 15:45 UTC (permalink / raw)
To: Ludovic Courtès, Danny Milosavljevic; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]
On 2018-09-10, Ludovic Courtès <ludo@gnu.org> wrote:
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
>> finally, https://hydra.gnu.org/build/3044681 (flash-image armhf) built.
>>
>> Can we put it on the website at https://www.gnu.org/software/guix/download/
>> inside the GuixSD part?
>>
>> I think it would be nice to have something ready-to-go for ARM systems as well,
>> and this would be a good start. Apart from the bootloader, everything should
>> work as-is in there. And the user can either keep the original bootloader
>> on the board or flash a new one after booting GuixSD - either in qemu or
>> on a real machine.
>
> I agree that it would be nice, but to what extent is this image generic
> to all ARM boards? My understanding is that images are necessarily
> bound to a specific board.
An armhf image should generally be able to support most modern 32-bit
arm boards, and an aarch64 image should be able to support most 64-bit
boards. At least to the extent that they are supported in linux-libre.
As Danny said, the bootloader is board-specific. This would either be
present in firmware on the board itself, or need to be added to the
image itself or other boot media manually.
For systems that use a modern u-boot, this should work if the image
includes the generated /boot/extlinux/extlinux.conf, and the initrd
doesn't require any tweaks to the included modules.
For EFI systems, it would probably require installing the appropriate
grub-efi bits.
For maximal compatibility, it would be best if both the relevent u-boot
and EFI bits were installed; they don't necessarily conflict, and modern
u-boot even has an EFI implementation (though may not work on many armhf
systems).
For comparison, the supported debian-installer images have a two-part
image:
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/README.concatenateable_images
Which contains the board-specific bootloader firmware and the common
parts as two separate images.
This has the obvious downside of requiring more work from the end-user
to assemble the correct image with the advantage being that the common
parts (which is the vast majority of the image) are shipped only once.
I could see it making sense for guix to generate a common image, and
then using that common image as an input to generate an image with the
bootloader installed, but maybe the substitute servers wouldn't build
the generated images by default?
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ARMHF flash image - Put on website under GuixSD
2018-09-10 15:45 ` Vagrant Cascadian
@ 2018-09-10 20:54 ` Ludovic Courtès
0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2018-09-10 20:54 UTC (permalink / raw)
To: Vagrant Cascadian; +Cc: guix-devel
Hello Vagrant,
Vagrant Cascadian <vagrant@debian.org> skribis:
> An armhf image should generally be able to support most modern 32-bit
> arm boards, and an aarch64 image should be able to support most 64-bit
> boards. At least to the extent that they are supported in linux-libre.
>
> As Danny said, the bootloader is board-specific. This would either be
> present in firmware on the board itself, or need to be added to the
> image itself or other boot media manually.
>
> For systems that use a modern u-boot, this should work if the image
> includes the generated /boot/extlinux/extlinux.conf, and the initrd
> doesn't require any tweaks to the included modules.
>
> For EFI systems, it would probably require installing the appropriate
> grub-efi bits.
>
> For maximal compatibility, it would be best if both the relevent u-boot
> and EFI bits were installed; they don't necessarily conflict, and modern
> u-boot even has an EFI implementation (though may not work on many armhf
> systems).
OK.
> For comparison, the supported debian-installer images have a two-part
> image:
>
> https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/README.concatenateable_images
>
> Which contains the board-specific bootloader firmware and the common
> parts as two separate images.
Interesting.
> This has the obvious downside of requiring more work from the end-user
> to assemble the correct image with the advantage being that the common
> parts (which is the vast majority of the image) are shipped only once.
>
>
> I could see it making sense for guix to generate a common image, and
> then using that common image as an input to generate an image with the
> bootloader installed, but maybe the substitute servers wouldn't build
> the generated images by default?
We’d need to find how to generate these two parts of the image (maybe
that’d require changes to ‘guix system’ & co.?). Then we can have
continuous integration jobs for all the various parts, especially if the
board-specific part is small.
At any rate, this approach sounds more viable than uploading a dozen of
nearly-identical 1GB images to ftp.gnu.org. :-)
The way forward would be to find out what needs to be done in ‘guix
system’ to generate these image parts, adjust the “release” target in
Makefile.am, add some documentation under “System Installation” in the
manual, and possibly adjust the download page of the web site.
It’s not a trivial change because of all these bits that need to be
adjusted, but it’s doable. Who’d like to give it a go?
Thanks for explaining!
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread