Much valued debian people!

iam trying with an debian installation@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






--
Wonderful vim doku:
When a mapping triggers itself, it will run forever
WEB www.johannes-koehler.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jan 12, 2022 at 09:26:06PM +0100, Johannes 'kefko' Köhler wrote:

Much valued debian people!

Hi Johannes,

iam trying with an debian installation@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

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/).

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.

- thx and sincerely
kefko

Dom

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE3nQdMjP43a68372B4cmZEuiMSOEFAmHtMa4ACgkQ4cmZEuiM SOEcOg//eBVlIt1Ky0CZM0rbfXW7FuXwyaOdFTPLEMj7BVGIdUCTydFEzbteXcNU pqvfnmVuQNWLtiIqcbV9HfnXxJM+WaQtilHFXYAPakzzQp818t6w38TSIFXxs65R pjqRcZoOBEZ/1YQgT7ozk5fKkXkVyu2+PvczSxrVVF2gRJz8fAAKadunvzHVZKZw A5jShFcpFAgxyGCSQ1jFSSRmKRmTgCoiqcrPxTZ9RqxmDJmFMTesoCrqBXu/AYjc Bo0iNBRDqdtVJ+UR2KxapdU1fHUiJp+JCiwhM7/uf7DZmytf2WNwK+8Z0pWUuznK 5+77mihboq6u8lZRWnooux1gh+EFIqv7kzJmWYx7+Gtgo6f0Lllepmz0g7oTrvXt VevXUQ9UiXdGWuohQtjuFRbTOfGutV5HxRGrPAucKIXtR+dNohi/K0+kIlYNUlCq 7//LyIzh0gn8GgHPsIZ7gPDLHhoXQZo0C+vNF0sH6YERkprL2dNSRsjPlwaU5UD3 Njl2RYXDT1ajFuB+VhXQV4zh7fWg/edk0owvK2r3gZvaO4FToXtX/Rm9o6kjUueJ t9jRBJ8KI9t3gvRJ0oHkn76ay8Nt+PgoV+l+YMBFxuUJrIqO3+B589p6Re/xfQrX IJ0cs+DZGq4XCCIrsnD1l5AJMSQzsOiHu4HqHQoWPsj9gq76UMs=
=Kqw6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet

* Domenico Andreoli <cavok@debian.org> [2022-01-23 11:45]:

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.

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.

--
Martin Michlmayr
https://www.cyrius.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 24, 2022 at 07:53:47AM +0800, Martin Michlmayr wrote:

* Domenico Andreoli <cavok@debian.org> [2022-01-23 11:45]:

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.

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

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE3nQdMjP43a68372B4cmZEuiMSOEFAmHuNbsACgkQ4cmZEuiM SOHRaQ//XAC/mOuJc+pBTxFXKirjtYTrIBRlCAEgkhpi9KAxa5/AaU4xkOH51y0C 9pC2UKXa/LDrPI4UDwxv8XdVyOihkGTJ99vjJl0kg6XFanfyhKDwXMPmI4IMAN2Q xQ2GZkPQpbOrcQmALw4qM3VcHblGGH9L0oAG9qAu4g1L6pIO7Qy8rmHJDuJqaPpB uaKFnOr2vGMDKLxTLWVOdUwpuCnWtRtguwB/ia4UN2gTXII1Am3DiSMA8rNtc5yZ aqsRLcatEdKyE7GzonmETa5T80A5mJXtHwWkL1v312E+EOxSk+qNgrWbRmTAo4ck HjTC+oCKXCFBrqPnUj6naonm2K/gNvAWDBWENBjs8wbLpYZAQzKkUpw3yeN4vLju UMc02Aps5HLD4QxBnXpI/Ygxtk8Z0MWUW6UhYikkaoFegbpzybQ98j0f5w/wLA6j aBHapbewp6n3hKPJhkjFMxtMmDOUeuNUs+eBuKplQofPXTvfvY0EkmshwjQaWtzT UyEQcZteMxvzCF3qheSn2CYT92KjFgq1MeiWFSpM2C/ah/ck4HTbsHoZIKOU3bzy utpQfrOtlv+s9ED7/YiEyAq08H12XNzqDnNqIi8ghLoK8YciETodTjEso8U5mWeC IZkMqA2GozeHSrmV/vsDPbY8d5FiSMCaJzjoW9+Za6NU/uRZnjQ=
=PsD4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet

On 1/23/22 18:53, Martin Michlmayr wrote:

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

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Philippe Clérié <philippe@gcal.net> [2022-02-10 17:45]:

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.
--
Martin Michlmayr
https://www.cyrius.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/10/22 18:40, Martin Michlmayr wrote:

* Philippe Clérié <philippe@gcal.net> [2022-02-10 17:45]:

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.

:-)

Thanks.

Now I need to make time to just dive in.

:-)

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Jo, 10 feb 22, 17:45:27, Philippe Clérié wrote:

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
--
http://wiki.debian.org/FAQsFromDebianUser

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5E64jOIbhY42OXqk/8eFRO8iNBwFAmIGqtkACgkQ/8eFRO8i NBwtpQ//YhWuOE487mpH9gEM6RwnrUpNaPvTXtTz+4qJ4Mxdkn2UxCWrsDUy6knP Q2PA02Q9rfqGMJimOmXwjfVOCiTco0DHptnudwUsU3+uy9EgQN/6baKi8LzisRd3 T228BNQpMmOa350AV2OkyhYwZerTEl7JiNrYocEWa723BClNSH5N6Qn4oJL48Wmz WIyp6aJxWUmW8MwxdhSa4NdYg6z9+9QYwW9ZqGZAObgot+V9eMwMF8E2enYVWoqN j5jKyCt1GsmigccwA5G6fxqnpLZn6vAl2hsh4vQYP0MXILMCY/YjjO/+Ojl95rK4 vL+zT8WTNwInrGeYuucUbl3EJPgRXPlTqMpiPjOj+tP7GYHpOXk/ZMmGmh/nbDqm tRk3huEIh8SWJjTfLTmYfgKjFBg9kzTJtMrYNJ6lMaw/sSs6Cu6uLeu8vof45PxJ Ap7km4nqdbiaY8uQiKAh3BSlARt9u7qp19oRNgHuWHDI8XYUXB+rF3YGmty+Z1mr 5ZZQfdTcMbBdGJGHud8QHKkg1MzPUbWFBxrk/L1aV8MJjhgLIkvJfEDyOmE5XlkV 4kDyfMRE4PXoBU5oiaZE1X/cCmUVrxzHan4T1Uyjm9lHFxBHoEJVfNOZIsdBTyxa AzaxMU2GQR1+ZJMyvo6/FDB5UfjQBh0mM5kv0VqmrpiqqkrsDNY=
=h+Dg
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/11/22 13:28, Andrei POPESCU wrote:

On Jo, 10 feb 22, 17:45:27, Philippe Clérié wrote:

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.

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 12 February 2022 16:14:19 CET Philippe Clérié wrote:

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
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYgfXVgAKCRDXblvOeH7b bt2cAP9P+LRJRWjDUNlMsZrq9H1jrixyxsYYsv0IeteHEXyolwEAyl7zoc13QxSd 4r9JyieLSdjIYpYDn6Ucm3do+Er+Lgw=
=SaLP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Feb 12, 2022 at 10:14:19AM -0500, Philippe Clérié wrote:

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.

--
Len Sorensen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)