Armbian

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Armbian

Phil Endecott-14
Dear All,

What do you know about Armbian?  What do you think?

Is there any overlap between the Debain ARM people on this list
and the Armbian developers?

I recently bought an ODROID-HC1 to use as a basic NAS.  It's an
interesting board with an Exynos Coretex-A15 SoC and Ethernet
and SATA connectors, and a nice mechanical design for a single-
disk NAS.  Typically for ODROID it has manufacturer support
for only Ubuntu and Android, so I looked for good ways to
install Debian.  There is a DebianOn wiki page but it's very
convoluted.  For the first time I decided to try Armbian.

Very briefly, Armbian's main strength seems to be that they
have configurations and/or patches for U-Boot, the kernel, and
related stuff for a good selection of ARM boards which are
kept up to date and seem to work pretty reliably.  They have
a build system and infrastructure that seems to rebuild these
as often as needed.  There is also a reasonably responsive
user/developer forum.

Installation involves downloading an SD card (or similar)
image which boots directly into a functioning system (with only
a few first-boot steps like initial user/password setting and
possibly resizing the filesystem to fill the device).  This
reminds me more of how the Debian cloud images work than
Debian Installer.  On devices like the ODROID-HC1 where you
are very likely to have a large disk as well as the boot
device, there is a script to move everything over.

Once installed, the system is almost but not quite regular
Debian.  For example, there are obvious things like a verbose
motd that reports the CPU temperature and more subtle differences
like /var/log being on a RAM disk.  I have been gradually
trying to make the system more "vanilla" but it's not always
clear if there will be side effects from e.g. removing or
disabling these Armbian things.

Debian on ARM does suffer a bit, IMHO, from a lack of
"official" installation support on many of the popular
boards.  So we end up with things like Raspian.  Unlike
Raspian, Armbian has NOT rebuilt the package archive; it
uses official Debain ARM packages.

Anyway, this all makes me wonder if there could or should
be closer collaboration here.  For example, should Debian ARM
be actively steering people towards Armbian as a way to get
Debian onto their ARM boards?  Could, perhaps, we have some
way to launch regular Debian Installer and get a regular
Debian system, after bootstrapping using Armbian?

Any thoughts or experiences to share?


Regards, Phil.







Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Reco
        Hi.

On Sun, Feb 02, 2020 at 05:33:43PM +0000, Phil Endecott wrote:
> What do you know about Armbian?  What do you think?

Own kernel, mostly Debian userland.
An interesting set of patches on top of vanilla kernel, definitely
controversial approach to DFSG.
Also, Armbian uses cross-compilation to build their packages, and it's a
good question if someone there had a single thought about building
packages in a reproducible way.


> I recently bought an ODROID-HC1 to use as a basic NAS.

ORDOID HC2 works perfectly with the stock Debian packages only from the
main archive (as of buster), and a couple of blobs. Judging from [1] -
same goes for HC1, save for the bootloader and blobs.


> It's an interesting board with an Exynos Coretex-A15 SoC and Ethernet
> and SATA connectors,

USB-based Ethernet and a single SATA connector, to be specific.
That severely limits overall usefulness of the board for NAS purpose.
Of course, if 300Mbps over unencrypted NFSv4 and a lack of disk
redundancy is something you're content with - my congratulations with
the purchase.
I use HC2 as a backup host only.


> and a nice mechanical design for a single-disk NAS.

Passive cooling is not enough for HC2.
I had to resort to putting two HC2s to USB-powered laptop cooling pad,
else prolonged use of HDD heated the boards to 70C and more.
YMMV if your plan to use SSD.


> Typically for ODROID it has manufacturer support only Ubuntu and
> Android,

... and said support is not that great in my experience.
Also, if ODROID says "Ubuntu", they really mean "Ubuntu with our 4.9
Android kernel and a ungodly pile of blobs just for the fun of it".


> so I looked for good ways to install Debian.  There is a DebianOn wiki
> page but it's very convoluted.

[1] basically tells you that some assembly is required, and tells about
the process. Not that hard, if you ask me.
Of course, it would be better if the page told about running d-i on a
board (perfectly possible BTW save the u-boot part) - but apparently
page's author is a big fan of debootstrap.
There are harder ARM boards in that regard (Raspberry Pi 4 or ODROID N2
to name a few).


> Very briefly, Armbian's main strength seems to be that they
> have configurations and/or patches for U-Boot, the kernel, and
> related stuff for a good selection of ARM boards which are
> kept up to date and seem to work pretty reliably.

I've yet to see an announcement from Armbian at oss-security maillist.
E-mails from Debian Developers land at oss-security within a day of
publishing DSA.

Reco

[1] https://wiki.debian.org/InstallingDebianOn/OdroidHC1

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Alan Corey
Arnbian is too much of what I don't like about Debian, full of little
specialized scripts for this and that with new ones coming out
practically weekly.  If you're used to living without them and they
break something because they're suddenly required it isn't
appreciated.  I don't re-read documentation to see if somebody changed
something.

The best thing about Armbian is that it's a good way to test a board
that may not be working.  I used it on my Rock64 that I thought might
be dead, it wasn't, then I went on to an Ayufan image.  They're
working hard at making these little things into appliances that
anybody can run and having them mostly all work the same.  Not for
everybody.

On 2/2/20, Reco <[hidden email]> wrote:

> Hi.
>
> On Sun, Feb 02, 2020 at 05:33:43PM +0000, Phil Endecott wrote:
>> What do you know about Armbian?  What do you think?
>
> Own kernel, mostly Debian userland.
> An interesting set of patches on top of vanilla kernel, definitely
> controversial approach to DFSG.
> Also, Armbian uses cross-compilation to build their packages, and it's a
> good question if someone there had a single thought about building
> packages in a reproducible way.
>
>
>> I recently bought an ODROID-HC1 to use as a basic NAS.
>
> ORDOID HC2 works perfectly with the stock Debian packages only from the
> main archive (as of buster), and a couple of blobs. Judging from [1] -
> same goes for HC1, save for the bootloader and blobs.
>
>
>> It's an interesting board with an Exynos Coretex-A15 SoC and Ethernet
>> and SATA connectors,
>
> USB-based Ethernet and a single SATA connector, to be specific.
> That severely limits overall usefulness of the board for NAS purpose.
> Of course, if 300Mbps over unencrypted NFSv4 and a lack of disk
> redundancy is something you're content with - my congratulations with
> the purchase.
> I use HC2 as a backup host only.
>
>
>> and a nice mechanical design for a single-disk NAS.
>
> Passive cooling is not enough for HC2.
> I had to resort to putting two HC2s to USB-powered laptop cooling pad,
> else prolonged use of HDD heated the boards to 70C and more.
> YMMV if your plan to use SSD.
>
>
>> Typically for ODROID it has manufacturer support only Ubuntu and
>> Android,
>
> ... and said support is not that great in my experience.
> Also, if ODROID says "Ubuntu", they really mean "Ubuntu with our 4.9
> Android kernel and a ungodly pile of blobs just for the fun of it".
>
>
>> so I looked for good ways to install Debian.  There is a DebianOn wiki
>> page but it's very convoluted.
>
> [1] basically tells you that some assembly is required, and tells about
> the process. Not that hard, if you ask me.
> Of course, it would be better if the page told about running d-i on a
> board (perfectly possible BTW save the u-boot part) - but apparently
> page's author is a big fan of debootstrap.
> There are harder ARM boards in that regard (Raspberry Pi 4 or ODROID N2
> to name a few).
>
>
>> Very briefly, Armbian's main strength seems to be that they
>> have configurations and/or patches for U-Boot, the kernel, and
>> related stuff for a good selection of ARM boards which are
>> kept up to date and seem to work pretty reliably.
>
> I've yet to see an announcement from Armbian at oss-security maillist.
> E-mails from Debian Developers land at oss-security within a day of
> publishing DSA.
>
> Reco
>
> [1] https://wiki.debian.org/InstallingDebianOn/OdroidHC1
>
>


--
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Paul Wise via nm
In reply to this post by Phil Endecott-14
On Sun, Feb 2, 2020 at 5:51 PM Phil Endecott wrote:

> What do you know about Armbian?  What do you think?

Only what I see on their site and derivatives census page:

https://www.armbian.com/
https://wiki.debian.org/Derivatives/Census/Armbian

I think they are a useful source of workarounds for devices that are
not yet supported in the mainline versions of bootloaders, the Linux
kernel or in Debian itself.

> Is there any overlap between the Debain ARM people on this list
> and the Armbian developers?

AFAICT, the Armbian folks don't post on this mailing list.

> Installation involves downloading an SD card (or similar)
> image which boots directly into a functioning system (with only
> a few first-boot steps like initial user/password setting and
> possibly resizing the filesystem to fill the device).  This
> reminds me more of how the Debian cloud images work than
> Debian Installer.  On devices like the ODROID-HC1 where you
> are very likely to have a large disk as well as the boot
> device, there is a script to move everything over.

Image-based installation methods are currently very hacky. After
installing packages, you will have system-specific files created (like
/etc/machine-id or OpenSSH private keys). The Debian live/cloud images
have to workaround that by deleting the files after the install is
created. Probably that set of deletions needs to be synced between
Debian live/cloud and any future ARM images (not sure if they are
synced yet). The correct way to do this would be for packages to have
a "generically installed" state in dpkg/apt, which would prevent them
from creating system-specific files. More info about this is in the
linked discussions:

https://wiki.debian.org/ReproducibleInstalls
https://wiki.debian.org/SystemBuildTools#Discussions

The other problem with image-based installation methods is that there
are a ridiculous number of devices, so you have to either limit your
device support, produce a prohibitively large amount of
device-specific images, or figure out how to create one image that
works on all devices (which won't be possible due to bootloader
diversity on ARM), or a compromise of a limited number of images that
each work on a range of devices. Limiting the number of images is also
complicated by some devices not having mainline Linux kernel support,
so you need to then install multiple versions of Linux and somehow
have the bootloader figure out which one to install, which also bloats
the size of the images.

> Once installed, the system is almost but not quite regular
> Debian.  For example, there are obvious things like a verbose
> motd that reports the CPU temperature and more subtle differences
> like /var/log being on a RAM disk.  I have been gradually
> trying to make the system more "vanilla" but it's not always
> clear if there will be side effects from e.g. removing or
> disabling these Armbian things.

cruft/cruft-ng might be useful to figure out which parts of the system
are shipped in Armbian but aren't from packages.

> Debian on ARM does suffer a bit, IMHO, from a lack of
> "official" installation support on many of the popular
> boards.  So we end up with things like Raspian.  Unlike
> Raspian, Armbian has NOT rebuilt the package archive; it
> uses official Debain ARM packages.

The Debian Installer supports various boards, but probably will never
be able to support the range of boards Armbian does, simply because
not all boards have support in bootloaders/Linux upstream and not all
boards can run without blobs of some kind. This situation is unlikely
to change until board manufacturers decide to upstream their patches
before selling their boards. The Linux kernel community (especially
Linaro) is working on changing that though.

> Anyway, this all makes me wonder if there could or should
> be closer collaboration here.  For example, should Debian ARM
> be actively steering people towards Armbian as a way to get
> Debian onto their ARM boards?  Could, perhaps, we have some
> way to launch regular Debian Installer and get a regular
> Debian system, after bootstrapping using Armbian?

The collaboration should mainly happen upstream in the bootloader and
Linux kernel communities and then Debian and other ARM based Linux
distros will inherit that work.

You can certainly boot Armbian, debootstrap a new Debian install, copy
over the Armbian versions of the bootloader and Linux kernel and any
other needed customisations.

You can probably also repack the Debian Installer ISO/initramfs files
to include the Armbian versions of bootloaders/Linux.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Paul Wise via nm
In reply to this post by Reco
On Sun, Feb 2, 2020 at 6:57 PM Reco wrote:

> [1] basically tells you that some assembly is required, and tells about
> the process. Not that hard, if you ask me.
> Of course, it would be better if the page told about running d-i on a
> board (perfectly possible BTW save the u-boot part) - but apparently
> page's author is a big fan of debootstrap.

> [1] https://wiki.debian.org/InstallingDebianOn/OdroidHC1

Feel free to register an account and add the d-i based install method.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

peter green-2
In reply to this post by Paul Wise via nm
On 03/02/2020 01:20, Paul Wise wrote:
> The other problem with image-based installation methods is that there
> are a ridiculous number of devices, so you have to either limit your
> device support, produce a prohibitively large amount of
> device-specific images, or figure out how to create one image that
> works on all devices (which won't be possible due to bootloader
> diversity on ARM),

D-I "solved" this problem by creating "concatenatable images", so you have a small stub image that is board-specific and contains the partition table and first stage bootloader, which you concatenate to the main board-independent image. I don't see any reason why you couldn't do the same for pre-installed images.

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Vagrant Cascadian-4
In reply to this post by Paul Wise via nm
On 2020-02-03, Paul Wise wrote:

> On Sun, Feb 2, 2020 at 5:51 PM Phil Endecott wrote:
>
>> What do you know about Armbian?  What do you think?
>
> Only what I see on their site and derivatives census page:
>
> https://www.armbian.com/
> https://wiki.debian.org/Derivatives/Census/Armbian
>
> I think they are a useful source of workarounds for devices that are
> not yet supported in the mainline versions of bootloaders, the Linux
> kernel or in Debian itself.
Nicely put!


> Image-based installation methods are currently very hacky. After
> installing packages, you will have system-specific files created (like
> /etc/machine-id or OpenSSH private keys). The Debian live/cloud images
> have to workaround that by deleting the files after the install is
> created. Probably that set of deletions needs to be synced between
> Debian live/cloud and any future ARM images (not sure if they are
> synced yet). The correct way to do this would be for packages to have
> a "generically installed" state in dpkg/apt, which would prevent them
> from creating system-specific files. More info about this is in the
> linked discussions:
>
> https://wiki.debian.org/ReproducibleInstalls
> https://wiki.debian.org/SystemBuildTools#Discussions
I have been meaning to explore making live images for arm devices using
the concatenateable images method used by debian-installer. Though, that
method has limitations too, as some devices load files off of a
partition, some off of raw device offsets, some a combination of those
methods. Some require MBR partition tables, some require GPT... it's a
big world out there. The great thing about standards, is...


It's also possible to have bootloader on one media that is device
specific, which doesn't take much space, and on a larger media image a
common rootfs, maybe also with EFI bootable grub-efi on it or something.
The U-boot support for EFI is coming along quite well.


> The other problem with image-based installation methods is that there
> are a ridiculous number of devices, so you have to either limit your
> device support, produce a prohibitively large amount of
> device-specific images, or figure out how to create one image that
> works on all devices (which won't be possible due to bootloader
> diversity on ARM), or a compromise of a limited number of images that
> each work on a range of devices.

A great talk from last year's fosdem addressing this issue with some
success:

  https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/


live well,
  vagrant

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Andreas Jellinghaus-3
In reply to this post by Reco
Hi Reco,

I wrote the guide for OdroidHC1, happy to answer any questions.

To share some background: initially I was looking into a custom sdcard image build by debian.
I remember finding some, but no one could tell me I could extend that list of automatic generated images.

Also the blobs required to boot the device are not part of debian, not even available in non-free. I reached out to hardkernel and asked them formally to add a license for the signed files, as that would be a requirement for distributions like debian to be able to ship them (in non-free at least). But that didn't end up nowhere.

The debian installer sounds great in theory, but in practice you install from one medium to a second medium. But with the device I have there is just a single medium: the sdcard I enter. The disk or ssd can be added optionally, or you can add a usb stick, but neither can boot without a sdcard having a boot loader already. So I'm not sure a D-I installer image would be that helpful. But then, having two options available doesn't hurt.

Regards, Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Andrei POPESCU-2
On Lu, 03 feb 20, 21:46:09, Andreas Jellinghaus wrote:
>
> The debian installer sounds great in theory, but in practice you install
> from one medium to a second medium. But with the device I have there is
> just a single medium: the sdcard I enter. The disk or ssd can be added
> optionally, or you can add a usb stick, but neither can boot without a
> sdcard having a boot loader already. So I'm not sure a D-I installer image
> would be that helpful. But then, having two options available doesn't hurt.

It's possible to install also to the same medium, see

https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Paul Wise via nm
In reply to this post by Vagrant Cascadian-4
On Mon, Feb 3, 2020 at 6:52 AM Vagrant Cascadian wrote:

> A great talk from last year's fosdem addressing this issue with some
> success:
>
>   https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/

That looks like a fairly useful workaround today, but ultimately it
seems unsustainable as more SoC and board vendors come out.

What we really need is for ARM to define a set of standards for SBC
boot ROMs and also require their licensees abide by those standards.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Uwe Kleine-König-7
In reply to this post by Andreas Jellinghaus-3
Hello,

On 2/3/20 9:46 PM, Andreas Jellinghaus wrote:
> The debian installer sounds great in theory, but in practice you install
> from one medium to a second medium. But with the device I have there is
> just a single medium: the sdcard I enter.

I don't know the capabilities of the vendor U-Boot, but I already
installed Debian successfully on some machines by just starting the
installer via tftp.

Of course you need console access and network support in U-Boot. But in
my bubble this isn't very exceptional.

See
https://blog.kleine-koenig.org/ukl/installing-debian-stretch-on-a-turris-omnia.html
for how that can work.

Best regards
Uwe


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Armbian

deloptes-2
Uwe Kleine-König wrote:

> I don't know the capabilities of the vendor U-Boot, but I already
> installed Debian successfully on some machines by just starting the
> installer via tftp.

unfortunately tftp and usb boot are not (yet) officially working on RPI 4

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Reco
In reply to this post by Andreas Jellinghaus-3
        Hi.

On Mon, Feb 03, 2020 at 09:46:09PM +0100, Andreas Jellinghaus wrote:
> I wrote the guide for OdroidHC1, happy to answer any questions.

Thank you for your work. I used that page as a template for two
successful HC2 Debian installations.

> Also the blobs required to boot the device are not part of debian, not even
> available in non-free.

I'm aware of that. Non-free blobs remain non-free regardless of their
origin though.

> I reached out to hardkernel and asked them formally
> to add a license for the signed files, as that would be a requirement for
> distributions like debian to be able to ship them (in non-free at least).
> But that didn't end up nowhere.

And that's the support quality of ODROID I wrote about earlier.

> The debian installer sounds great in theory, but in practice you install
> from one medium to a second medium.

Why? All you need is d-i kernel, initrd and dtb put into the same sdcard
that you've used to install u-boot and aforementioned blobs.
Next you just use u-boot to load the kernel, initrd and dtb and enjoy
the sight of d-i running on a real hardware, installing real Debian on
the very same sdcard.
With the only possible culprit being the installation of u-boot itself
(by d-i) itself, in the case that Debian-provided u-boot is unable to
function on that particular board. Which is not the case for HC2, but I
lack HC1 to check it.

Reco

Reply | Threaded
Open this post in threaded view
|

Re: Armbian

Domenico Andreoli-3
In reply to this post by Vagrant Cascadian-4
On Sun, Feb 02, 2020 at 10:43:37PM -0800, Vagrant Cascadian wrote:

> On 2020-02-03, Paul Wise wrote:
> > On Sun, Feb 2, 2020 at 5:51 PM Phil Endecott wrote:
> >
>
> > Image-based installation methods are currently very hacky. After
> > installing packages, you will have system-specific files created (like
> > /etc/machine-id or OpenSSH private keys). The Debian live/cloud images
> > have to workaround that by deleting the files after the install is
> > created. Probably that set of deletions needs to be synced between
> > Debian live/cloud and any future ARM images (not sure if they are
> > synced yet). The correct way to do this would be for packages to have
> > a "generically installed" state in dpkg/apt, which would prevent them
> > from creating system-specific files. More info about this is in the
> > linked discussions:
> >
> > https://wiki.debian.org/ReproducibleInstalls
> > https://wiki.debian.org/SystemBuildTools#Discussions
>
> I have been meaning to explore making live images for arm devices using
> the concatenateable images method used by debian-installer. Though, that
> method has limitations too, as some devices load files off of a
> partition, some off of raw device offsets, some a combination of those
> methods. Some require MBR partition tables, some require GPT... it's a
> big world out there. The great thing about standards, is...

Andre Przywara made a nice talk at FOSDEM 2019 about booting on multiple
devices using the same image:

https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/

When GPT [0] is limited to 4 partitions it fits in the envelope of
MBR. With fdisk it's possible to create such configuration, I could try
to add the needed support to the D-I if that opens to new combinations.

Regards,
Dom

[0] https://en.wikipedia.org/wiki/GUID_Partition_Table

--
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05