Re: odroid hc1 on debian?
On Wed, Nov 1, 2017 at 4:40 PM, Andreas Jellinghaus wrote:
> * after inserting an sd card into a desktop with debian, gnome file explorer
> or whatever pops up, if there are filesystems on the partition. Close those
> and unmount the partition first.
I guess you have automount turned on, it can be turned off:
https://askubuntu.com/questions/89244/how-to-disable-automount-in-nautiluss-preferences
> * I have to configure a password (TODO: at least force a password change on
> first login)
Debian has never done first-boot configuration, it is always done in d-i.
> * wait a second between parted and mkfs to allow udev to catch up.
I think you can also run partprobe here to poke Linux/udev.
> * mkfs wants a confirmation, if the sd card had a filesystem before.
You should use wipefs before mkfs so that no filesystem drivers detect
a filesystem on the device, if multiple different filesystems were
detected, that could end up in a weird situation.
> * with /etc/network/interfaces I try to configure dhcp on eth0. Actually the
> interface gets renamed based on the MAC - how do I configure that? Does
> /etc/network/interface allow "*" pattern or similar?
With ifupdown from buster and later, you can do pattern matching:
https://manpages.debian.org/testing/ifupdown/interfaces.5.en.html#PATTERN_MATCHING_INTERFACES
> * For my own use case using the whole size of the SD card is proper, thus I
> use parted with 100% setting. For creating a downloadable image it would be
> better to configure it as small as possible, then have code in place to
> resize the partition and filesystem at the first boot.
The Debian cloud images do that IIRC, you could use one of those.
> A current bug in dash causes dash&bash packages not to be configured with
> DEBIAN_FRONTEND=noninteractive. dpkg --configure -a without that option
> works, but creates an interactive dialog step.
If this isn't reported, please do report it:
https://www.debian.org/Bugs/Reporting
> That said, except for the required arm cpu firmware blobs from hardkernel,
It would be great if these could be opened and added to u-boot.
Otherwise talk HardKernel into getting those included in
linux-firmware (or fwupd):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
https://fwupd.org/
> So how can we go forward here? I had to reach out to the wiki team to
> create/enable an account, so can't edit it right now.
Created.
> ... the ecosystem for everyone. How can we get there? Is debian-installer the
> only route, or is some team/group/... also covering the typical SBC use case
> of ready-installed images?
Debian doesn't produce any official per-device images, we do have live
and cloud images though. Some developers produce specific images for
devices they own though. I don't think producing specific images for
specific devices can scale, since every device is different. Armbian
has been going this route btw.
> It is a shame how much fine tuning gets reinvented in this space all the
> time, I guess all items from my laundry list above have been found and fixed
> by others in some way many times already. Any Debian forum for consolidating
> such work and creating debian images?
We have been talking about this problem at DebConf officially since at
least 2009 (and remember talking about it informally in DebConf7) and
people keep reinventing the wheel instead of using one of the many
standard solutions, so I doubt this problem will ever go away.
https://wiki.debian.org/SystemBuildTools#Talks
> The SD Card must be set up to contain 2MB of unused space at the start,
> then a boot partition (readable by U-Boot), then the root filesystem.
I think the flash-kernel source package is the place to hard-code
these details? Or maybe the tool that builds the d-i images, not sure.
> multistrap is a new tool similar to debootstrap, but without using a tar.gz
AFAIK debootstrap doesn't use a tar.gz, what are you referring to here?
> cp /usr/bin/qemu-arm-static /mnt/usr/bin/
You can skip this by using qemu-debootstrap.
> git clone https://github.com/hardkernel/u-boot -b odroidxu4-v2017.05
Please talk to HardKernel about upstreaming their u-boot patches.
Looks like they already did it for odroidxu3:
https://packages.debian.org/sid/armhf/u-boot-exynos/filelist
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: