Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #60565 > unrolled thread

Re: D-Link DNS-323 support dropped in Debian stretch

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: D-Link DNS-323 support dropped in Debian stretch Roger Shimizu <rogershimizu@gmail.com> - 2018-03-26 12:40 +0200
    Re: D-Link DNS-323 support dropped in Debian stretch basti <mailinglist@unix-solution.de> - 2018-03-26 14:20 +0200
    Re: D-Link DNS-323 support dropped in Debian stretch Leigh Brown <leigh@solinno.co.uk> - 2018-03-26 18:10 +0200
    Re: D-Link DNS-323 support dropped in Debian stretch Aaro Koskinen <aaro.koskinen@iki.fi> - 2018-03-27 20:50 +0200
      Re: D-Link DNS-323 support dropped in Debian stretch Ian Campbell <ijc@debian.org> - 2018-03-28 10:50 +0200
        Re: D-Link DNS-323 support dropped in Debian stretch Roger Shimizu <rogershimizu@gmail.com> - 2018-03-28 12:20 +0200
    Re: D-Link DNS-323 support dropped in Debian stretch Martin Michlmayr <tbm@cyrius.com> - 2018-03-28 03:30 +0200

#60565 — Re: D-Link DNS-323 support dropped in Debian stretch

[ loop debian-kernel ML ]

On Mon, Mar 26, 2018 at 7:05 PM, Martin Michlmayr <tbm@cyrius.com> wrote:
> * basti <mailinglist@unix-solution.de> [2018-03-26 12:00]:
>> Can it be an option to run Stretch with older Kernel from jessie?
>
> I don't know.
>
>> And can you please explain why it is dropped, I see that qnap TS-x09 is
>> still supported.
>
> DNS-323 only has 1.5 MB space for the kernel.  TS-x09 has 2 MB.  We're
> constantly pushing against these limits.  1.5 MB wasn't doable in
> stretch and 2 MB is no longer doable in buster.

armel support for sid kernel was (temporally) disabled last month, due
to over size (>2MB).
I just added armel back last weekend by extend the limit from 2MB to
2.7MB, which means it drops support for qnap.

There's one possibility that can bring back qnap, or even D-Link DNS device:
- create a new flavour for armel, such as armel-none-mini
- the new flavour will disable many features that other common kernels
have, such as wireless, crypto, etc.

The question is whether it deserves the effort, not only creating the
new flavour, but also maintaining it during the whole buster period.
So I want to know how many active users for D-Link DNS and QNAP devices now?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [next] | [standalone]

#60566

On 26.03.2018 12:36, Roger Shimizu wrote:
> So I want to know how many active users for D-Link DNS and QNAP devices now?
> 
> Cheers,
> 

Hello Roger,

I Plan to reactivate my DNS-323 for Tests and MPD Usage.
I also have some QNAP TS (TS-219P, TS-219P+, 2x TS-421) all are
Production Systems.

[toc] | [prev] | [next] | [standalone]

#60567

Hello,

On 2018-03-26 11:36, Roger Shimizu wrote:
> [ loop debian-kernel ML ]
> 
> On Mon, Mar 26, 2018 at 7:05 PM, Martin Michlmayr <tbm@cyrius.com> 
> wrote:
>> * basti <mailinglist@unix-solution.de> [2018-03-26 12:00]:
>>> Can it be an option to run Stretch with older Kernel from jessie?
>> 
>> I don't know.
>> 
>>> And can you please explain why it is dropped, I see that qnap TS-x09 
>>> is
>>> still supported.
>> 
>> DNS-323 only has 1.5 MB space for the kernel.  TS-x09 has 2 MB.  We're
>> constantly pushing against these limits.  1.5 MB wasn't doable in
>> stretch and 2 MB is no longer doable in buster.

I think with a small amount of effort it can be done.

> armel support for sid kernel was (temporally) disabled last month, due
> to over size (>2MB).
> I just added armel back last weekend by extend the limit from 2MB to
> 2.7MB, which means it drops support for qnap.

I'm pleased it has returned because I have two Dreamplugs and they load
the kernel from SD and there is no 2MB limitation.  I am using Stock
Debian with a stock kernel and stock u-boot, which I am very pleased 
about.

> There's one possibility that can bring back qnap, or even D-Link DNS 
> device:
> - create a new flavour for armel, such as armel-none-mini
> - the new flavour will disable many features that other common kernels
> have, such as wireless, crypto, etc.

I certainly think that if people are using Debian successfully then some
effort should be expended to continue support if the hardware still 
works.

I've done this before and these custom kernels tend to be quite tailored
to the device, which may result in quite a few variants.  Is that 
possible?

> The question is whether it deserves the effort, not only creating the
> new flavour, but also maintaining it during the whole buster period.
> So I want to know how many active users for D-Link DNS and QNAP devices 
> now?

Here is a patch that will reduce the size of the kernel a bit and 
doesn't
(in my opinion) make the kernel any less useable (or less "Debian").  
I'm
not aware of any Marvell devices that would need VT support, is that 
correct?

-rw-r--r-- 1 leigh leigh 1986320 Mar 23 12:10 vmlinuz-4.16.0-rc6-marvell

Regards,

Leigh.
-- 

diff --git a/debian/config/armel/config.marvell 
b/debian/config/armel/config.marvell
index c5703aeeb..7235cb767 100644
--- a/debian/config/armel/config.marvell
+++ b/debian/config/armel/config.marvell
@@ -121,6 +121,7 @@ CONFIG_SUN_PARTITION=y
  ##
  # CONFIG_CRYPTO_FIPS is not set
  CONFIG_CRYPTO_SHA256=m
+CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y

  ##
  ## file: drivers/ata/Kconfig
@@ -633,6 +634,11 @@ CONFIG_FB_XGI=m
  ##
  CONFIG_THERMAL=m
  CONFIG_KIRKWOOD_THERMAL=m
+#
+##
+## file: drivers/tty/Kconfig
+##
+# CONFIG_VT is not set

  ##
  ## file: drivers/tty/serial/8250/Kconfig
@@ -754,6 +760,8 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
  ## file: lib/Kconfig.debug
  ##
  # CONFIG_SCHEDSTATS is not set
+# CONFIG_CRC32_SLICEBY8 is not set
+CONFIG_CRC32_SLICEBY4=y

  ##
  ## file: mm/Kconfig

[toc] | [prev] | [next] | [standalone]

#60580

Hi,

On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote:
> There's one possibility that can bring back qnap, or even D-Link DNS device:
> - create a new flavour for armel, such as armel-none-mini
> - the new flavour will disable many features that other common kernels
> have, such as wireless, crypto, etc.

Disable all other features, except what's needed for disk access and kexec
(perhaps still leave serial console :)). Then with simple scripting boot
the full featured kernel from external storage using kexec. Such minimal
kernel should be fairly stable from maintenance point of view.

A.

[toc] | [prev] | [next] | [standalone]

#60591

On Tue, 2018-03-27 at 21:25 +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote:
> > There's one possibility that can bring back qnap, or even D-Link
> > DNS device:
> > - create a new flavour for armel, such as armel-none-mini
> > - the new flavour will disable many features that other common
> > kernels
> > have, such as wireless, crypto, etc.
> 
> Disable all other features, except what's needed for disk access and kexec
> (perhaps still leave serial console :)). Then with simple scripting boot
> the full featured kernel from external storage using kexec. Such minimal
> kernel should be fairly stable from maintenance point of view.

This, and similar things (like chainloading a more capable u-boot),
have been suggested repeatedly over the last few years, what is needed
is for someone to actually try/do it.

Ian.

[toc] | [prev] | [next] | [standalone]

#60594

On Wed, Mar 28, 2018 at 5:40 PM, Ian Campbell <ijc@debian.org> wrote:
> On Tue, 2018-03-27 at 21:25 +0300, Aaro Koskinen wrote:
>> Hi,
>>
>> On Mon, Mar 26, 2018 at 07:36:26PM +0900, Roger Shimizu wrote:
>> > There's one possibility that can bring back qnap, or even D-Link
>> > DNS device:
>> > - create a new flavour for armel, such as armel-none-mini
>> > - the new flavour will disable many features that other common
>> > kernels
>> > have, such as wireless, crypto, etc.
>>
>> Disable all other features, except what's needed for disk access and kexec
>> (perhaps still leave serial console :)). Then with simple scripting boot
>> the full featured kernel from external storage using kexec. Such minimal
>> kernel should be fairly stable from maintenance point of view.
>
> This, and similar things (like chainloading a more capable u-boot),
> have been suggested repeatedly over the last few years, what is needed
> is for someone to actually try/do it.

Yet another solution suggested repeatedly is chained u-boot.
If you can load a modern u-boot, you already take control over your
device and load any kernel image you want.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#60589

* Roger Shimizu <rogershimizu@gmail.com> [2018-03-26 19:36]:
> So I want to know how many active users for D-Link DNS and QNAP devices now?

I don't think there were ever many DNS-323 users.  QNAP has an active
user base but the hardware is aging, so I think they will be able to
cope without buster (especially if LTS stretch could be done for
armel).

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web