uboot@qnap - debian

[Johannes 'kefko' Köhler]

Much valued debian people!

iam trying with an debian ***@qnap ts-109...

I already had a running jessie installation, but the
dist moved to archived and therefore the possibility to
run this working setting is past hence, or gone.

Now... I retried with the currently stretch installer,
and the routine is running proper, but without leaving
a bootable uboot setting to myself@ nonvolatile ram

The installer rejected the uuid for the root device
within /var/log/syslog, but i fixed it and then
not anymore an error message. Kernel and initrd got flashed
to device like the installer told me...

Resetting the qnap ends in the uboot loader screen
(through serial tty). At within the uboot shell i realized
debian bootcmd arguments were not set-up.

Searching pages was not effective at all. Maybe someone
can give me a hard or softlink to some good documentation,
or code examples... OR still has an answer to my
problem.

- thx and sincerely
kefko

[Domenico Andreoli]

Post by Johannes 'kefko' Köhler
Much valued debian people!

Hi Johannes,

Post by Johannes 'kefko' Köhler
I already had a running jessie installation, but the
dist moved to archived and therefore the possibility to
run this working setting is past hence, or gone.
Now... I retried with the currently stretch installer,
and the routine is running proper, but without leaving

Any reason for installing Stretch?

In case you want to try with something more recent, Buster is the latest
Debian to support these QNAP.

Bullseye is also possible (although not officially supported) but
only as upgrade from Buster and after some manual fiddling (see
https://cyrius.com/debian/orion/qnap/).

Post by Johannes 'kefko' Köhler
The installer rejected the uuid for the root device
within /var/log/syslog, but i fixed it and then
not anymore an error message. Kernel and initrd got flashed
to device like the installer told me...
Resetting the qnap ends in the uboot loader screen
(through serial tty). At within the uboot shell i realized
debian bootcmd arguments were not set-up.
Searching pages was not effective at all. Maybe someone
can give me a hard or softlink to some good documentation,
or code examples... OR still has an answer to my
problem.

https://cyrius.com/debian/orion/qnap/ is a good starting point.

Post by Johannes 'kefko' Köhler
- thx and sincerely
kefko

Dom

[Martin Michlmayr]

Post by Domenico Andreoli
Any reason for installing Stretch?
In case you want to try with something more recent, Buster is the latest
Debian to support these QNAP.

The installer isn't available for buster on Orion devices (only
Kirkwood); stretch is the latest.

Post by Domenico Andreoli
Bullseye is also possible (although not officially supported) but
only as upgrade from Buster and after some manual fiddling (see

The manual fiddling only works on Kirkwood, not Orion. With the
Kirkwood-devices, there's enough MTD flash (the problem is the
partition layout). The Orion-based devices only have 8 MB flash,
which isn't enough.

[Domenico Andreoli]

Post by Martin Michlmayr

Post by Domenico Andreoli
Any reason for installing Stretch?
In case you want to try with something more recent, Buster is the latest
Debian to support these QNAP.

The installer isn't available for buster on Orion devices (only
Kirkwood); stretch is the latest.

Post by Domenico Andreoli
Bullseye is also possible (although not officially supported) but
only as upgrade from Buster and after some manual fiddling (see

The manual fiddling only works on Kirkwood, not Orion. With the
Kirkwood-devices, there's enough MTD flash (the problem is the
partition layout). The Orion-based devices only have 8 MB flash,
which isn't enough.

My apologies for having spread wrong info.
Thanks Martin for correcting me :)

Dom

[Philippe Clérié]

Post by Martin Michlmayr
The manual fiddling only works on Kirkwood, not Orion. With the
Kirkwood-devices, there's enough MTD flash (the problem is the
partition layout). The Orion-based devices only have 8 MB flash,
which isn't enough.

I am curious about the manual fiddling.

If I read this paragraph correctly, the implication is that the flash
device partitioning can be changed to accommodate the larger kernels.
Presumably from uboot.

I do have several devices that I have retired or am about to retire that
could be salvaged if that is possible. I think *armel* may get another
few years reprieve since Debian based its Pi OS on *armel* instead of
*armhf*. (A rather surprising decision!)

Are there any instructions, guides or other documentation for how to get
it done?

Thanks in advance

[Martin Michlmayr]

If I read this paragraph correctly, the implication is that the flash device
partitioning can be changed to accommodate the larger kernels. Presumably
from uboot.

...

Are there any instructions, guides or other documentation for how to get it
done?

Arnaud Mouiche, who created a script that re-configures the partition layout
on QNAP, also wrote excellent documentation about the whole thing:

https://github.com/amouiche/qnap_mtd_resize_for_bullseye

The summary is that you can pass "mtdparts" as a kernel parameter to
set the partition layout.

[Philippe Clérié]

Post by Martin Michlmayr

If I read this paragraph correctly, the implication is that the flash device
partitioning can be changed to accommodate the larger kernels. Presumably
from uboot.

...

Are there any instructions, guides or other documentation for how to get it
done?

Arnaud Mouiche, who created a script that re-configures the partition layout
https://github.com/amouiche/qnap_mtd_resize_for_bullseye
The summary is that you can pass "mtdparts" as a kernel parameter to
set the partition layout.

:-)

Thanks.

Now I need to make time to just dive in.

:-)

[Andrei POPESCU]

I think *armel* may get another few
years reprieve since Debian based its Pi OS on *armel* instead of *armhf*.
(A rather surprising decision!)

Might there be some confusion here?

Debian doesn't have a "Pi OS" and it was rather unfortunate the first
Raspberry Pi was launched *after* the baseline for Debian's armhf was
already decided. The only pure Debian that would work on the Raspberry
Pi was armel.

That is why Raspbian (the predecessor of Raspberry Pi OS from the
Raspberry Pi Foundation) was born, it was basically Debian's armhf
recompiled for the first Raspberry Pi.

You can follow the state of Debian architectures at
https://release.debian.org/bookworm/arch_qualify.html.

At the moment it looks good for bookworm, though it's still early in the
release cycle and even so, support for specific hardware might be
dropped for independent reasons.

Kind regards,
Andrei

[Philippe Clérié]

Post by Andrei POPESCU

I think *armel* may get another few
years reprieve since Debian based its Pi OS on *armel* instead of *armhf*.
(A rather surprising decision!)

Might there be some confusion here?
Debian doesn't have a "Pi OS" and it was rather unfortunate the first
Raspberry Pi was launched *after* the baseline for Debian's armhf was
already decided. The only pure Debian that would work on the Raspberry
Pi was armel.
That is why Raspbian (the predecessor of Raspberry Pi OS from the
Raspberry Pi Foundation) was born, it was basically Debian's armhf
recompiled for the first Raspberry Pi.
You can follow the state of Debian architectures at
https://release.debian.org/bookworm/arch_qualify.html.
At the moment it looks good for bookworm, though it's still early in the
release cycle and even so, support for specific hardware might be
dropped for independent reasons.
Kind regards,
Andrei

My apologies for the confusion. *Pi OS* here was meant as a shortcut for
the *official* distribution of Debian for the Raspberry Pi. Which I am
using by the way.

[Diederik de Haas]

Post by Philippe Clérié
My apologies for the confusion. *Pi OS* here was meant as a shortcut for
the *official* distribution of Debian for the Raspberry Pi. Which I am
using by the way.

Which is still confusing, because I'm not aware of an 'official distribution of
Debian for the RPi'.
I am aware of https://raspi.debian.net/ but that says explicitly:
"This site is not an official Debian project. While the maintainer (Gunnar Wolf)
is a Debian Developer, content herein provided should be considered unofficial."

It uses/depends on raspi-firmware which is non-free software and therefor can
not be part of Debian ('officially').

The provided images do consist purely of packages provided via the Debian
archives, so I'm assuming you meant that.

Do note that 'armel' is only used for the RPi Zero and RPi 1, because as
mentioned earlier, those hardware devices do not conform to Debian's armhf
requirements.
The RPi 2 does and therefor the images use packages from the armhf ARCH.
The RPi 3 and 4 are 64-bit capable and therefor run arm64.

The linux-image-rpi package for bullseye-backports, bookworm and sid now
explicitly mention it's only for RPi Zero, Zero W and 1, which hopefully
reduces potential confusion.

HTH,
Diederik

[Lennart Sorensen]

My apologies for the confusion. *Pi OS* here was meant as a shortcut for the
*official* distribution of Debian for the Raspberry Pi. Which I am using by
the way.

The pi is just one of the systems you can run Debian on. armel being the
only one an armv6 could run since armhf quite sensibly picked armv7 since
there was a lot of those around and very few armv6 systems. The fact
broadcom decided to put an armv6 into a video chip and someone then
decided to turn that into a system (even though the armv6 was probably
not a great choice for that use case) could not have been predicted.
Adding another arm architecture on top of armel and armhf just because
of the pi would not have made sense and of course the Pi 2 and newer
are all capable of using armhf, so it was only the first Pi that had a
problem (and I must admit I was never interested in the first pi since
to me that was just way too under powered to be useful, while I do have
both a 2 and a 3).

I actually consider it lucky the pi wasn't out when armhf's requirements
were done or we might have ended up with armv6 as the baseline due to
a single system, cripling all the other armv7 boards.