Just tried arm64 netinstall on a bananai-m5

[gene heskett]

used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
bring card back to reader, can't mount it, wrong filesystem for both
partitions. Give up, write Armbian-jammie-full-desktop iso to card,
mounts ok, boots bananapi-m5 normally.

What did I do wrong?

Cheers, Gene Heskett.

[Vagrant Cascadian]

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
bring card back to reader, can't mount it, wrong filesystem for both
partitions. Give up, write Armbian-jammie-full-desktop iso to card,
mounts ok, boots bananapi-m5 normally.
What did I do wrong?

Hard to say based on so little information...

My wild guess is the Armbian-jammie-full-desktop iso includes boot
firmware.

Do you have a URL to the exact image you used?

Do you have any output from the serial console when trying to boot the
Debian image? Armbian?

The only way what you did might work is if you have boot firmware
present on some other media (e.g. SPI, eMMC, etc.) that implements EFI,
such as edk2/tianocore or u-boot.

live well,
vagrant

[gene heskett]

Post by Vagrant Cascadian

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
bring card back to reader, can't mount it, wrong filesystem for both
partitions. Give up, write Armbian-jammie-full-desktop iso to card,
mounts ok, boots bananapi-m5 normally.
What did I do wrong?

Hard to say based on so little information...
My wild guess is the Armbian-jammie-full-desktop iso includes boot
firmware.

unk to me

Post by Vagrant Cascadian
Do you have a URL to the exact image you used?

The most recent build, 12-1 of the arm64 menu on debians quite confusing
web page. I didn't bookmark the URL

Post by Vagrant Cascadian
Do you have any output from the serial console when trying to boot the
Debian image? Armbian?

debian-12.1.0-arm64-netinst.iso
Armbian_23.5.1_Bananapim5_jammy_current_6.1.30.img

Post by Vagrant Cascadian
The only way what you did might work is if you have boot firmware
present on some other media (e.g. SPI, eMMC, etc.) that implements EFI,
such as edk2/tianocore or u-boot.

I take it that debian is not ready to boot on just any old arm64. So
while I've installed about 4 more gigs of jammie, I have yet to see a
gui package manager because its usung wayland and wayland doesn't allow
anything needing root. wayland will have arrived when we have a gui
based package manager that unlike aptitude, speaks english. Something
that tells us whats its going to do BEFORE it does it.

So what I am in the midst of doing, is with the huge amount of trash
installed, used gparted for partition and label the 16Gb emmc that it
not used into something I can save the working network stuff to, saved
it all and will now start with a new card with the bare jammie on it,
boot that, mount the 16G emmc, restore the networking stuff reboot and
continue my search for enough stuff including xorg & nginx, to run a 3d
printer with kiauh handling that install on a system that is not
contaminated with the 800 pkgs gnome pulled in.

Post by Vagrant Cascadian
live well,

I have indeed done that for 88 years. I wish I had room left in the wet
ram for half of what you've done. Thank you, a lot.

Post by Vagrant Cascadian
vagrant

Cheers, Gene Heskett.

[peter green]

used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC ONN. brand card, makes no attempt to boot plugged into a bananapi-m5. bring card back to reader, can't mount it, wrong filesystem for both partitions. Give up, write Armbian-jammie-full-desktop iso to card, mounts ok, boots bananapi-m5 normally.
What did I do wrong?

The unfortunate reality is that boot on arm is *still* a mess. The server guys and the windows laptop guys
have settled on uefi (though the implementations are often far from perfect), but the hobbyist board segment
is still all over the place, with each board (or family of closely related boards) still needing it's own build
of u-boot that knows how to initialise the board, load a kernel and initrd and pass them the relavent device
tree.

For some boards, Debian offers "concatenatable images", where a board-specific boot section can be concatenated
with a board-independent d-i section to produce a boot image suitable for a specific board, yours doesn't seem
to be one of them though.

.

[Alan Corey]

Seems to me it would be a good target to shoot for having "make
menuconfig" encompass hardware choices as well as others, so the
hardware is just another choice in the menu.

Post by peter green

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
bring card back to reader, can't mount it, wrong filesystem for both
partitions. Give up, write Armbian-jammie-full-desktop iso to card, mounts
ok, boots bananapi-m5 normally.
What did I do wrong?

The unfortunate reality is that boot on arm is *still* a mess. The server
guys and the windows laptop guys
have settled on uefi (though the implementations are often far from
perfect), but the hobbyist board segment
is still all over the place, with each board (or family of closely related
boards) still needing it's own build
of u-boot that knows how to initialise the board, load a kernel and initrd
and pass them the relavent device
tree.
For some boards, Debian offers "concatenatable images", where a
board-specific boot section can be concatenated
with a board-independent d-i section to produce a boot image suitable for a
specific board, yours doesn't seem
to be one of them though.
.

[Marcin Juszkiewicz]

Post by peter green

Post by gene heskett
What did I do wrong?

The unfortunate reality is that boot on arm is *still* a mess. The
server guys and the windows laptop guys have settled on uefi (though
the implementations are often far from perfect), but the hobbyist
board segment is still all over the place, with each board (or family
of closely related boards) still needing it's own build of u-boot

It is not "U-Boot versus UEFI" problem.

The problem is SBC vendors who go with "Shitty Bargain Crap" explanation
of acronym instead of "Small Board Computer" one.

When you have SBC without any on-board storage for boot firmware
(nevermind is it U-Boot, UEFI, Barebox or whatever) then you need to
provide (usually) microsd with firmware stored at some magical places.

One of solutions then is to make microsd card with firmware, put it into
a slot and forget that microsd slot exists. Then you can plug USB stick
with Debian installer (just "dd if=debian.iso of=/dev/usbstick") and boot.

This is how raspberry/pi 1/2/3 and several other SBC work.

[gene heskett]

Post by Marcin Juszkiewicz

Post by peter green

Post by gene heskett
What did I do wrong?

The unfortunate reality is that boot on arm is *still* a mess. The
server guys and the windows laptop guys have settled on uefi (though
the implementations are often far from perfect), but the hobbyist
board segment is still all over the place, with each board (or family
of closely related boards) still needing it's own build of u-boot

It is not "U-Boot versus UEFI" problem.
The problem is SBC vendors who go with "Shitty Bargain Crap" explanation
of acronym instead of "Small Board Computer" one.
When you have SBC without any on-board storage for boot firmware
(nevermind is it U-Boot, UEFI, Barebox or whatever) then you need to
provide (usually) microsd with firmware stored at some magical places.
One of solutions then is to make microsd card with firmware, put it into
a slot and forget that microsd slot exists. Then you can plug USB stick
with Debian installer (just "dd if=debian.iso of=/dev/usbstick") and boot.
This is how raspberry/pi 1/2/3 and several other SBC work.

That is an option I've not been advised of, I'll get some usb keys and
try it. Thank you.

Post by Marcin Juszkiewicz
.

Cheers, Gene Heskett.

[gene heskett]

Post by peter green

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G
SDXC ONN. brand card, makes no attempt to boot plugged into a
bananapi-m5. bring card back to reader, can't mount it, wrong
filesystem for both partitions. Give up, write
Armbian-jammie-full-desktop iso to card, mounts ok, boots bananapi-m5
normally.
What did I do wrong?

The unfortunate reality is that boot on arm is *still* a mess. The
server guys and the windows laptop guys
have settled on uefi (though the implementations are often far from
perfect), but the hobbyist board segment
is still all over the place, with each board (or family of closely
related boards) still needing it's own build
of u-boot that knows how to initialise the board, load a kernel and
initrd and pass them the relavent device
tree.
For some boards, Debian offers "concatenatable images", where a
board-specific boot section can be concatenated
with a board-independent d-i section to produce a boot image suitable
for a specific board, yours doesn't seem
to be one of them though.

All no doubt true. But once this board is booted, its 20% faster than
any pi, but doesn't have, and I don't need, a wifi radio. And every usb
port is usb3.
\
Thank you Peter Green.

Post by peter green
.
.

Cheers, Gene Heskett.

[Andrew M.A. Cater]

Post by peter green

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G
SDXC ONN. brand card, makes no attempt to boot plugged into a
bananapi-m5. bring card back to reader, can't mount it, wrong
filesystem for both partitions. Give up, write
Armbian-jammie-full-desktop iso to card, mounts ok, boots
bananapi-m5 normally.
What did I do wrong?

Fairly straightforwardly: as it stands at the moment, your board is
not supported by mainstream Debian. As outlined on debian-user

* Armbian builds based on board support packages (BSP)
* They add Debian/Ubuntu userland
* You have no idea how they're booting

Post by peter green
The unfortunate reality is that boot on arm is *still* a mess. The
server guys and the windows laptop guys
have settled on uefi (though the implementations are often far from
perfect), but the hobbyist board segment
is still all over the place, with each board (or family of closely
related boards) still needing it's own build
of u-boot that knows how to initialise the board, load a kernel and
initrd and pass them the relavent device
tree.

You can probably build u-boot, use debootstrap from one of these
banana-pi 5s running "Debian" but it will mean work and you'll need to
know how big the kernel needs to be / at what offset or similar.
That's the sort of thing that vagrantc has done a lot of in the past.

You're at a disadvantage because none of the rest of us likely have these
boards or will ever see them. That's where having a Beaglebone Black / a
Raspberry Pi really scores.

Post by peter green
For some boards, Debian offers "concatenatable images", where a
board-specific boot section can be concatenated
with a board-independent d-i section to produce a boot image suitable
for a specific board, yours doesn't seem
to be one of them though.

There are concatenable images for earlier bananapis - this might be
a good point to start by working out what needs to go into the board
specific part. These images can be dd'ed to an SD card to boot - once
they work.

All no doubt true. But once this board is booted, its 20% faster than any
pi, but doesn't have, and I don't need, a wifi radio. And every usb port is
usb3.
\
Thank you Peter Green.

Post by peter green
.
.

Some assembly required :) You're an old-school electronics engineer, as
you remind us. It's as if someone says to you "If you can't get the
Einac power tube you need, try this Soviet / E German model. Power output's
the same but the bias may be different. Oh, and it's fatter, so you'll need
a different chimney for the cooling air flow"

That's the scale of the difference between these random ARM SBC's - if
you don't want to change anything and you have all the bits round them,
they're fine. Otherwise, you have to work round your own limitations and
how much effort you want to put in.

All best,

Andy

[And there's some attribution missing above]

Cheers, Gene Heskett.
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

[Marco d'Itri]

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
bring card back to reader, can't mount it, wrong filesystem for both
partitions. Give up, write Armbian-jammie-full-desktop iso to card,
mounts ok, boots bananapi-m5 normally.
What did I do wrong?

As explained, this board is not supported by the Debian Installer and it
will probably never be since it requires a custom u-boot with
binary-only parts.

But if you recover the u-boot from an Armbian image then you can still
install plain Debian:

https://blog.bofh.it/debian/id_466

(As long as you do not care about the SD card reader, at this point.)

[gene heskett]

Post by Marco d'Itri

Post by gene heskett
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC
ONN. brand card, makes no attempt to boot plugged into a bananapi-m5.
bring card back to reader, can't mount it, wrong filesystem for both
partitions. Give up, write Armbian-jammie-full-desktop iso to card,
mounts ok, boots bananapi-m5 normally.
What did I do wrong?

As explained, this board is not supported by the Debian Installer and it
will probably never be since it requires a custom u-boot with
binary-only parts.
But if you recover the u-boot from an Armbian image then you can still
https://blog.bofh.it/debian/id_466

That probably works, but is a long & complex procedure for some not
intimately fam with uboot. + I'm already using mmcblk1p1 for other
purposes. Also the current jammy does not have the udev bug debian has
said will not be fixed until the release /after/ trixie. Thats
unfortunate because it disables many 3d printers from running the better
klipper instead of marlin. klipper for errorless com demands the
/dev/serial/by-id, matching the chipmakers SN to the exact board.

Armbian Jammy Just Works here and has been for months, where/what is the
uboot bug mentioned in that blog? In this case, details matter, a lot.

Thank you.

Post by Marco d'Itri
(As long as you do not care about the SD card reader, at this point.)

Cheers, Gene Heskett.