• uboot@qnap - debian

    From =?UTF-8?Q?Johannes_=27kefko=27_K=c3@21:1/5 to All on Wed Jan 12 21:30:01 2022
    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)
  • From Domenico Andreoli@21:1/5 to All on Sun Jan 23 11:50:01 2022
    On Wed, Jan 12, 2022 at 09:26:06PM +0100, Johannes 'kefko' Khler 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
  • From Martin Michlmayr@21:1/5 to All on Mon Jan 24 01:00:01 2022
    * 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)
  • From Domenico Andreoli@21:1/5 to Martin Michlmayr on Mon Jan 24 06:20:02 2022
    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
  • From =?UTF-8?B?UGhpbGlwcGUgQ2zDqXJpw6k=?@21:1/5 to Martin Michlmayr on Fri Feb 11 00:00:01 2022
    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)
  • From Martin Michlmayr@21:1/5 to All on Fri Feb 11 01:00:01 2022
    * Philippe Clri <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)
  • From =?UTF-8?B?UGhpbGlwcGUgQ2zDqXJpw6k=?@21:1/5 to Martin Michlmayr on Fri Feb 11 17:20:01 2022
    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)
  • From Andrei POPESCU@21:1/5 to All on Fri Feb 11 19:30:01 2022
    On Jo, 10 feb 22, 17:45:27, Philippe Clri 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)
  • From =?UTF-8?B?UGhpbGlwcGUgQ2zDqXJpw6k=?@21:1/5 to Andrei POPESCU on Sat Feb 12 16:20:01 2022
    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)
  • From Diederik de Haas@21:1/5 to All on Sat Feb 12 16:50:46 2022
    On Saturday, 12 February 2022 16:14:19 CET Philippe Clri 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)
  • From Lennart Sorensen@21:1/5 to All on Sat Feb 12 19:00:01 2022
    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)