ukl's bloghttps://blog.kleine-koenig.org/ukl/2024-01-14T21:08:00+01:00PGP Keysigning on FOSDEM'242024-01-08T08:34:00+01:002024-01-14T21:08:00+01:00tag:blog.kleine-koenig.org,2024-01-08:/ukl/pgp-keysigning-on-fosdem24.html<p>I'm going to <a href="https://fosdem.org/2024/">FOSDEM'24</a>. Assuming to meet Debian and
Kernel folks there, this should be a good opportunity to do PGP keysigning.</p>
<p>If you also go there and you're interested in keysigning: Send me your key via
email to fosdem24-keysigning@kleine-koenig.org. I'll collect the keys, create a
paper list …</p><p>I'm going to <a href="https://fosdem.org/2024/">FOSDEM'24</a>. Assuming to meet Debian and
Kernel folks there, this should be a good opportunity to do PGP keysigning.</p>
<p>If you also go there and you're interested in keysigning: Send me your key via
email to fosdem24-keysigning@kleine-koenig.org. I'll collect the keys, create a
paper list for a keysigning party and send it back to you in the week before
FOSDEM. The list will only be made available to other participants.</p>
<p>Then maybe wear a "keysigning" badge (or a crepe tape with that caption) that
allows us to identify others on the list. If there are not too many who are
interested, I guess that should work fine. (If this idea becomes too
successful, I'd close the list after the first 100 participants.)</p>
<p>Update: Several people let me know there is another keysigning announced on
<a href="https://ludovic.hirlimann.net/2024/01/key-signing-party-at-fosdem-2024.html">Ludovic Hirlimann's blog</a>.
So you might want to bring some more paper slips with your fingerprint and show up there, too.</p>Philips Hue Bridge v2.12019-11-14T12:00:00+01:002019-11-25T16:00:00+01:00tag:blog.kleine-koenig.org,2019-11-14:/ukl/philips-hue-bridge-v21.html<p>I recently bought a Hue Bridge to experiment a bit with Zigbee and 802.15.4.
Following <a href="https://forum.archive.openwrt.org/viewtopic.php?id=66346">two</a>
<a href="http://colinoflynn.com/2016/07/getting-root-on-philips-hue-bridge-2-0/">posts</a>
for the hardware version 2.0 and some comments about the differences to version
2.1 I was able to get shell access on my 2.1 hardware.</p>
<p>As there is …</p><p>I recently bought a Hue Bridge to experiment a bit with Zigbee and 802.15.4.
Following <a href="https://forum.archive.openwrt.org/viewtopic.php?id=66346">two</a>
<a href="http://colinoflynn.com/2016/07/getting-root-on-philips-hue-bridge-2-0/">posts</a>
for the hardware version 2.0 and some comments about the differences to version
2.1 I was able to get shell access on my 2.1 hardware.</p>
<p>As there is up to now no complete guide I describe here, what I did:</p>
<p>Opening the case is straigth forward. Just remove the two lower nubsis at the
bottom and unscrew the two torx screws; then carefully unclip the bottom.</p>
<p><img alt="PCB" src="images/philips-hue-pcb-small.jpg"></p>
<p>The header on the left side on the image gives access to the UART. Pin 1 is
ground, pin 4 is the board's RX (so connect your adapter's TX) and pin 5 is the
board's TX. The voltage level is 3.3 V. Note however that the board doesn't
boot (after a cold start) with its TX connected so leave that unconnected until
after the bootloader is up.</p>
<p>To stop the bootloader short the test point marked with a red cycle on the
image near the NAND flash to ground for a few seconds when plugging in the
power cord. I used pin 14 of SJ8 (the unassembled header on the left above the
factory reset button). This makes the bootloader fail to read the kernel image
from NAND and then drop to a shell.</p>
<p>Then after connecting RX you can do there:</p>
<div class="highlight"><pre><span></span><code><span class="k">setenv</span><span class="w"> </span><span class="nv">bootdelay</span><span class="w"> </span><span class="mi">3</span>
<span class="k">setenv</span><span class="w"> </span><span class="nv">security</span><span class="w"> </span><span class="s1">'$5$uaS2DwZOsch$2H76tTh0yLzH8LfIkg7z1icoYZLeLGV.Gpo3quhZSe2'</span>
<span class="nv">saveenv</span>
<span class="nv">reset</span>
</code></pre></div>
<p>After that the machine boots up and you can login with username <code>root</code> and
password <code>lala</code>. (If you want a different password, set <code>security</code> in U-Boot accordingly. I did</p>
<div class="highlight"><pre><span></span><code>mkpasswd -m sha-256
</code></pre></div>
<p>to generate the necessary string.)</p>
<p>After contacting Philips asking for the GPL code running on the bridge I got a
code drop and looked a bit around in the source code. Here are some findings:</p>
<p>Having the boards UART TX connected to an USB adapter influences the register
<code>RST_BOOTSTRAP</code> at offset <code>0x180600b0</code>. This is used to determine how memory is
initialized (in function <code>ath_ddr_initial_config</code> defined in
<code>qsdk/qca/src/qca-legacy-uboot/board/atheros/common/init-953x.c</code>). The naming
of the register together with the board's behaviour suggests that is it sampled
at cold boot only and bit0 then contains the state of the TX pin. So I guess
the machine not (cold) booting with TX connected could be fixed with a hardware
modification removing (or weakening) a pullup on my USB adapter. But I'm more
of a software guy with infinitesimal solder skills, so I will live with
reconnecting TX for each cold boot. Alternatively patching the bootloader to
ignore the <code>RST_BOOTSTRAP</code> might be an option.</p>
<p>I will keep you updated on any progress here.</p>Using the switch on Turris Omnia with Debian2018-03-23T17:43:00+01:002018-03-23T22:29:00+01:00tag:blog.kleine-koenig.org,2018-03-23:/ukl/using-the-switch-on-turris-omnia-with-debian.html<p>After <a href="https://blog.kleine-koenig.org/ukl/installing-debian-stretch-on-a-turris-omnia.html">installing Debian</a> on <a href="https://omnia.turris.cz/en/">Turris Omnia</a>
there are a few more steps needed to make use of the network switch.</p>
<p>The Armada 385 CPU provides three network interfaces. Two are connected to the
switch (but only one of them is used to "talk" to the switch), and one is
routed …</p><p>After <a href="https://blog.kleine-koenig.org/ukl/installing-debian-stretch-on-a-turris-omnia.html">installing Debian</a> on <a href="https://omnia.turris.cz/en/">Turris Omnia</a>
there are a few more steps needed to make use of the network switch.</p>
<p>The Armada 385 CPU provides three network interfaces. Two are connected to the
switch (but only one of them is used to "talk" to the switch), and one is
routed directly to the WAN port.</p>
<p>After booting you might have to issue the following commands to make the
devices representing the five external ports of the switch appear and functional:</p>
<div class="highlight"><pre><span></span><code><span class="gp"># </span>ip<span class="w"> </span>link<span class="w"> </span><span class="nb">set</span><span class="w"> </span>eth1<span class="w"> </span>up
<span class="gp"># </span>modprobe<span class="w"> </span>mv88e6xxx
</code></pre></div>
<p>After that you can use the network devices <code>lan0</code> to <code>lan4</code> like normal network
devices. To make them actually behave as you would expect from a network switch
you have to put them into a bridge. The driver then offloads forwarding between
the ports to the switch hardware such that the cpu doesn't need to bother for
each single packet.</p>
<p>To automate setup of the bridged ports I used <code>systemd-networkd</code> as follows:</p>
<div class="highlight"><pre><span></span><code><span class="gp"># </span><span class="nb">echo</span><span class="w"> </span>mv88e6xxx<span class="w"> </span>><span class="w"> </span>/etc/modules-load.d/switch.conf
<span class="gp"># </span><span class="nb">printf</span><span class="w"> </span><span class="s1">'[Match]\nPath=platform-f1030000.ethernet\n[Link]\n#MACAddress=...\nName=eth1\n'</span><span class="w"> </span>><span class="w"> </span>/etc/systemd/network/00-platform-f1030000-eth1.link
<span class="gp"># </span><span class="nb">printf</span><span class="w"> </span><span class="s1">'[NetDev]\nName=brlan\nKind=bridge\n'</span><span class="w"> </span>><span class="w"> </span>/etc/systemd/network/brlan.netdev
<span class="gp"># </span><span class="nb">printf</span><span class="w"> </span><span class="s1">'[Match]\nName=brlan\n\n[Network]\nLinkLocalAddressing=ipv6\n'</span><span class="w"> </span>><span class="w"> </span>/etc/systemd/network/brlan.network
<span class="gp"># </span><span class="nb">printf</span><span class="w"> </span><span class="s1">'[Match]\nName=lan[01234]\n\n[Network]\nBridge=brlan\nBindCarrier=eth1\n'</span><span class="w"> </span>><span class="w"> </span>/etc/systemd/network/lanX.network
<span class="gp"># </span><span class="nb">printf</span><span class="w"> </span><span class="s1">'[Match]\nName=eth1\n'</span><span class="w"> </span>><span class="w"> </span>/etc/systemd/network/eth1.network
<span class="gp"># </span>systemctl<span class="w"> </span><span class="nb">enable</span><span class="w"> </span>--now<span class="w"> </span>systemd-networkd.service
</code></pre></div>
<p>You also might want to mask NetworkManager and/or ifupdown to not interfere
with the above setup. And obviously you might want to add some more options to
<code>brlan.network</code> to configure the addresses used there. See
<a href="https://www.freedesktop.org/software/systemd/man/systemd.network.html">systemd.network(1)</a>.</p>IPv6 in my home network2017-09-17T12:15:00+02:002017-10-02T12:15:00+02:00tag:blog.kleine-koenig.org,2017-09-17:/ukl/ipv6-in-my-home-network.html<p>I am lucky and get both IPv4 (without CGNAT) and IPv6 from my provider.
Recently after upgrading my desk router (that is an Netgear WNDR3800 that
serves the network on my desk) from OpenWRT to latest LEDE I looked into what
can be improved in the IPv6 setup for both …</p><p>I am lucky and get both IPv4 (without CGNAT) and IPv6 from my provider.
Recently after upgrading my desk router (that is an Netgear WNDR3800 that
serves the network on my desk) from OpenWRT to latest LEDE I looked into what
can be improved in the IPv6 setup for both my home network (served by a
FRITZ!Box) and my desk network.</p>
<p>Unfortunately I was unable to improve the situation compared to what I already
had before.</p>
<h2>Things that work</h2>
<p>Making IPv6 work in general was easy, just a few clicks in the configuration of the FRITZ!Box and it mostly worked. After that I have:</p>
<ul>
<li>IPv6 connectivity in the home net</li>
<li>IPv6 connectivity in the desk net</li>
</ul>
<h2>Things that don't work</h2>
<p>There are a few things however that I'd like to have, that are not that easy it
seems:</p>
<h3>ULA for both nets</h3>
<p>I let the two routers announce an ULA prefix each. Unfortunately I was unable
to make the LEDE box announce its net on the wan interface for clients in the
home net. So the hosts in the desk net know how to reach the hosts in the home
net but not the other way round which makes it quite pointless. (It works fine
as long as the FRITZ!Box announces a global net, but I'd like to have local
communication work independent of the global connectivity.)</p>
<p>To fix this I'd need something like <code>radvd</code> on my LEDE router, but that isn't
provided by LEDE (or OpenWRT) any more as <code>odhcpd</code> is supposed to be used which
AFAICT is unable to send RAs on the wan interface though. Ok, probably I could
install <code>bird</code>, but that seems a bit oversized. I created an <a href="https://forum.lede-project.org/t/sending-ipv6-router-advertisments-to-wan-interface-about-ula-prefix/6577/1">entry in the LEDE
forum</a>
but without any reply up to now.</p>
<p>Alternatively (but less pretty) I could setup an IPv6 route in the FRITZ!Box,
but that only works with a newer firmware and as this router is owned by my
provider I cannot update it.</p>
<h3>Firewalling</h3>
<p>The FRITZ!Box has a firewall that is not very configurable. I can punch a hole
in it for hosts with a given interface-ID, but that only works for hosts in the
home net, not the machines in the delegated subnet behind the LEDE router. In
fact I think the FRITZ!Box should delegate firewalling for a delegated net also
to the router of that subnet.</p>
<p>So having a global address on the machines on my desk doesn't allow me to reach
them from the internet.</p>
<p>Update: according to the German changelog firmware 6.83 seems to include that
feature. Cheers AVM. Now waiting for my provider to update ...</p>Installing Debian Stretch on a Turris Omnia2016-11-08T21:56:00+01:002016-11-17T10:36:00+01:00tag:blog.kleine-koenig.org,2016-11-08:/ukl/installing-debian-stretch-on-a-turris-omnia.html<p>Recently I got "my" Turris Omnia and it didn't take long to replace the
original firmware with Debian.</p>
<p>If you want to reproduce, here is what you have to do:</p>
<p>Open the case of the Turris Omnia, connect the hacker pack (or an RS232-to-TTL
adapter) to access the U-Boot prompt …</p><p>Recently I got "my" Turris Omnia and it didn't take long to replace the
original firmware with Debian.</p>
<p>If you want to reproduce, here is what you have to do:</p>
<p>Open the case of the Turris Omnia, connect the hacker pack (or an RS232-to-TTL
adapter) to access the U-Boot prompt (see <a href="https://www.youtube.com/watch?v=LVhzU5dzZCI">Turris Omnia: How to use the "Hacker
pack"</a>). Then download the
installer and device tree:</p>
<div class="highlight"><pre><span></span><code><span class="gp"># </span><span class="nb">cd</span><span class="w"> </span>/srv/tftp
<span class="gp"># </span>wget<span class="w"> </span>https://d-i.debian.org/daily-images/armhf/daily/netboot/vmlinuz
<span class="gp"># </span>wget<span class="w"> </span>https://d-i.debian.org/daily-images/armhf/daily/netboot/initrd.gz
<span class="gp"># </span>wget<span class="w"> </span>https://www.kleine-koenig.org/tmp/armada-385-turris-omnia.dtb
</code></pre></div>
<p>(The latter is not included yet in Debian, but I'm working on that.)</p>
<p>and after connecting the Turris Omnia's WAN to a dhcp managed network start it
in U-Boot:</p>
<div class="highlight"><pre><span></span><code><span class="go">dhcp</span>
<span class="go">setenv serverip 192.168.1.17</span>
<span class="go">tftpboot 0x01000000 vmlinuz</span>
<span class="go">tftpboot 0x02000000 armada-385-turris-omnia.dtb</span>
<span class="go">tftpboot 0x03000000 initrd.gz</span>
<span class="go">bootz 0x01000000 0x03000000:$filesize 0x02000000</span>
</code></pre></div>
<p>With <code>192.168.1.17</code> being the IPv4 of the machine you have the tftp server
running.</p>
<p>I suggest to use btrfs as rootfs because that works well with U-Boot.
Before finishing the installation put the dtb in the rootfs as /boot/dtb.</p>
<p>To then boot into Debian do in U-Boot:</p>
<div class="highlight"><pre><span></span><code><span class="go">setenv mmcboot=btrload mmc 0 0x01000000 boot/vmlinuz\; btrload mmc 0 0x02000000 boot/dtb\; btrload mmc 0 0x03000000 boot/initrd.img\; bootz 0x01000000 0x03000000:$filesize 0x02000000</span>
<span class="go">setenv bootargs console=ttyS0,115200 rootfstype=btrfs rootdelay=2 root=/dev/mmcblk0p1 rootflags=commit=5 rw</span>
<span class="go">saveenv</span>
<span class="go">boot</span>
</code></pre></div>
<p>Known issues:</p>
<ul>
<li>rtc doesn't work (workaround: <code>mw 0xf10184a0 0xfd4d4cfa</code> in U-Boot)</li>
<li>SFP and switch don't work, MAC addresses are random</li>
<li>wifi fails to probe</li>
</ul>
<p>If you have problems, don't hesitate to contact me.</p>
<p>Also check the <a href="https://wiki.debian.org/InstallingDebianOn/TurrisOmnia">Debian Wiki</a> for further details.</p>Fixing Debian bug #7942662016-08-01T23:13:00+02:002016-08-01T23:13:00+02:00tag:blog.kleine-koenig.org,2016-08-01:/ukl/fixing-debian-bug-794266.html<p>After finally being able to fix
<a href="https://bugs.debian.org/794266">Debian bug #794266</a> I want to thank those who
made this possible:</p>
<p>Some time ago my colleague Bjørn offered an
<a href="http://www.acmesystems.it/arietta">Arietta G25</a> to me. After Jochen, another
colleague, helped me to solder pin headers on it, this machine served as host
computer for my …</p><p>After finally being able to fix
<a href="https://bugs.debian.org/794266">Debian bug #794266</a> I want to thank those who
made this possible:</p>
<p>Some time ago my colleague Bjørn offered an
<a href="http://www.acmesystems.it/arietta">Arietta G25</a> to me. After Jochen, another
colleague, helped me to solder pin headers on it, this machine served as host
computer for my tests.</p>
<p>As I didn't have a machine with the relevant RTC chip, I contacted Seiko
Instruments and they provided me a few chips including oscillators. It was
again Jochen who then created a break-out board from these components that I
could wire to my Arietta board.</p>
<p>Finally Wolfram Sang's <a href="https://lkml.org/lkml/2015/2/27/350">i2ctransfer</a>
helped me a lot to access and so understand the chip. It's has not landed in
i2c-tools.git, but I hope this will change soon given that this is a really
useful tool.</p>
<p>A big thank you to all who helped me. It was fun and would have been less so
without your efforts! </p>Christoph Hellwig vs VMware2016-02-23T09:20:00+01:002016-02-23T09:20:00+01:00tag:blog.kleine-koenig.org,2016-02-23:/ukl/christoph-hellwig-vs-vmware.html<p>On Thursday the lawsuit about GPL compliance of VMware's ESXi products starts.
I support Christoph's position and share his view that VMware's product is in
conflict with the GPL.</p>
<p>Read more on <a href="https://sfconservancy.org/copyleft-compliance/vmware-lawsuit-faq.html">the software freedom conservancy's FAQ about the case</a>.</p>
<p>I keep my fingers crossed!</p>Let's encrypt2015-12-04T09:30:00+01:002015-12-04T09:30:00+01:00tag:blog.kleine-koenig.org,2015-12-04:/ukl/lets-encrypt.html<p><a href="https://letsencrypt.org">Let's encrypt</a> entered <a href="https://letsencrypt.org//2015/12/03/entering-public-beta.html">public
beta</a> and there
is a Debian package in experimental for their client available.</p>
<p>After some reading and testing I came up with the following commandline to give
me what I want:</p>
<div class="highlight"><pre><span></span><code><span class="n">letsencrypt</span><span class="w"> </span><span class="o">--</span><span class="n">manual</span><span class="w"> </span><span class="o">--</span><span class="n">config</span><span class="o">-</span><span class="n">dir</span><span class="w"> </span><span class="o">$</span><span class="n">HOME</span><span class="o">/</span><span class="n">letsencrypt</span><span class="o">/</span><span class="n">etc</span><span class="w"> </span>\
<span class="o">--</span><span class="n">work</span><span class="o">-</span><span class="n">dir</span><span class="w"> </span><span class="o">$</span><span class="n">HOME</span><span class="o">/</span><span class="n">letsencrypt</span><span class="o">/</span><span class="k">var</span><span class="w"> </span><span class="o">--</span><span class="n">logs</span><span class="o">-</span><span class="n">dir</span><span class="w"> </span><span class="o">$</span><span class="n">HOME …</span></code></pre></div><p><a href="https://letsencrypt.org">Let's encrypt</a> entered <a href="https://letsencrypt.org//2015/12/03/entering-public-beta.html">public
beta</a> and there
is a Debian package in experimental for their client available.</p>
<p>After some reading and testing I came up with the following commandline to give
me what I want:</p>
<div class="highlight"><pre><span></span><code><span class="n">letsencrypt</span><span class="w"> </span><span class="o">--</span><span class="n">manual</span><span class="w"> </span><span class="o">--</span><span class="n">config</span><span class="o">-</span><span class="n">dir</span><span class="w"> </span><span class="o">$</span><span class="n">HOME</span><span class="o">/</span><span class="n">letsencrypt</span><span class="o">/</span><span class="n">etc</span><span class="w"> </span>\
<span class="o">--</span><span class="n">work</span><span class="o">-</span><span class="n">dir</span><span class="w"> </span><span class="o">$</span><span class="n">HOME</span><span class="o">/</span><span class="n">letsencrypt</span><span class="o">/</span><span class="k">var</span><span class="w"> </span><span class="o">--</span><span class="n">logs</span><span class="o">-</span><span class="n">dir</span><span class="w"> </span><span class="o">$</span><span class="n">HOME</span><span class="o">/</span><span class="n">letsencrypt</span><span class="o">/</span><span class="n">logs</span><span class="w"> </span>\
<span class="o">--</span><span class="n">server</span><span class="w"> </span><span class="n">https</span><span class="p">:</span><span class="o">//</span><span class="n">acme</span><span class="o">-</span><span class="n">v01</span><span class="o">.</span><span class="n">api</span><span class="o">.</span><span class="n">letsencrypt</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">directory</span><span class="w"> </span>\
<span class="o">--</span><span class="n">domains</span><span class="w"> </span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">www</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">blog</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">lists</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">cgi</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">wiki</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">caldav</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="p">,</span><span class="n">mail</span><span class="o">.</span><span class="n">kleine</span><span class="o">-</span><span class="n">koenig</span><span class="o">.</span><span class="n">org</span><span class="w"> </span>\
<span class="n">certonly</span>
</code></pre></div>
<p>So now you can read this message via https and probably don't be bothered by
your browser for an invalid certificate any more. Hurray!</p>Alternative Firmware for a squeezebox2015-02-08T12:52:00+01:002015-02-08T12:52:00+01:00tag:blog.kleine-koenig.org,2015-02-08:/ukl/alternative-firmware-for-a-squeezebox.html<p>My Squeezebox Radio does its duty most of the time. Unfortunately it depends on
a single central service run by Logitech. Well, from time to time this service
doesn't work which makes me wish for an alternative firmware that doesn't
depend on such a service. Moreover it doesn't feel too …</p><p>My Squeezebox Radio does its duty most of the time. Unfortunately it depends on
a single central service run by Logitech. Well, from time to time this service
doesn't work which makes me wish for an alternative firmware that doesn't
depend on such a service. Moreover it doesn't feel too good that I can login to
mysqueezebox.com, press "Remote Control" and can control the box from there.</p>
<p>So here is my wish list for the alternative firmware:</p>
<ul>
<li>free and open source</li>
<li>local configuration without a central server</li>
<li>optionally controllable by http directly on the box</li>
<li>support DLNA to play music available in the local network</li>
<li>and last not least it should of course still play streams from the internet</li>
</ul>
<p>As a starter I ported <a href="http://www.barebox.org">barebox</a> to the Squeezebox.
Currently only second stage loadable for the vendor supplied Redboot and apart
from the UART no devices working yet. But still ...</p>
<p>Until I get further with porting a recent bootloader and Linux to it, feel free
to contact me if you have a link to a free internet radio firmware.</p>Installing Debian Jessie on a Netgear ReadyNAS 1042014-11-20T09:12:00+01:002016-01-27T12:03:00+01:00tag:blog.kleine-koenig.org,2014-11-20:/ukl/installing-debian-jessie-on-a-netgear-readynas-104.html<p>The Netgear ReadyNAS 104 comes shipped with U-Boot. To access its "shell"
remove the small quadratic sticker at the backside to reveal the UART pins
(3V3, pinout available at <a href="http://natisbad.org/NAS2/index.html#hw-serial">Arnaud's NAS page</a>[1]) and
connect a matching adapter. Also connect a network cable to the lower jack.</p>
<p>Then on a …</p><p>The Netgear ReadyNAS 104 comes shipped with U-Boot. To access its "shell"
remove the small quadratic sticker at the backside to reveal the UART pins
(3V3, pinout available at <a href="http://natisbad.org/NAS2/index.html#hw-serial">Arnaud's NAS page</a>[1]) and
connect a matching adapter. Also connect a network cable to the lower jack.</p>
<p>Then on a different machine in the same network setup a tftp server (e.g.
<code>apt-get install tftpd-hpa</code>). <del>As of today the latest beta netboot installer
(Beta 2) doesn't work any more because the kernel in jessie was updated since
the installer was released. So pick up the armhf netboot installer from the
<a href="http://d-i.debian.org/daily-images/armhf/daily/netboot/">daily snapshots</a>. You
need
<a href="http://d-i.debian.org/daily-images/armhf/daily/netboot/initrd.gz">initrd.gz</a>
and <a href="http://d-i.debian.org/daily-images/armhf/daily/netboot/vmlinuz">vmlinuz</a>.
Furthermore
<a href="http://d-i.debian.org/daily-images/armhf/daily/device-tree/armada-370-netgear-rn104.dtb">armada-370-netgear-rn104.dtb</a>.</del></p>
<p>Update: As jessie is released now, download the following images:</p>
<ul>
<li><a href="http://ftp.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/initrd.gz">initrd.gz</a></li>
<li><a href="http://ftp.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/vmlinuz">vmlinuz</a></li>
<li><a href="http://ftp.debian.org/debian/dists/jessie/main/installer-armhf/current/images/device-tree/armada-370-netgear-rn104.dtb">armada-370-netgear-rn104.dtb</a></li>
</ul>
<p>To make the installer ready to boot do:</p>
<div class="highlight"><pre><span></span><code><span class="gp"># </span>apt-get<span class="w"> </span>install<span class="w"> </span>u-boot-tools
<span class="gp">$ </span>cat<span class="w"> </span>vmlinuz<span class="w"> </span>armada-370-netgear-rn104.dtb<span class="w"> </span>><span class="w"> </span>vmlinuz-rn104
<span class="gp">$ </span>mkimage<span class="w"> </span>-A<span class="w"> </span>arm<span class="w"> </span>-O<span class="w"> </span>linux<span class="w"> </span>-T<span class="w"> </span>multi<span class="w"> </span>-C<span class="w"> </span>none<span class="w"> </span>-a<span class="w"> </span>0x04000000<span class="w"> </span>-e<span class="w"> </span>0x04000000<span class="w"> </span>-n<span class="w"> </span><span class="s2">"Debian Jessie armhf installer"</span><span class="w"> </span>-d<span class="w"> </span>vmlinuz-rn104:initrd.gz<span class="w"> </span>uImage-installer-rn104
<span class="gp"># </span>cp<span class="w"> </span>uImage-installer-rn104<span class="w"> </span>/srv/tftp
</code></pre></div>
<p>Then on the U-Boot shell setup networking and start the installer by issuing the following commands:</p>
<div class="highlight"><pre><span></span><code>dhcp
<span class="nb">setenv </span>serverip 192.168.1.17
tftp uImage-installer-rn104
bootm <span class="nv">$load_addr</span>
</code></pre></div>
<p>With <code>192.168.1.17</code> being the IPv4 of the machine you set up the tftp server
above, adapt accordingly to your setup.</p>
<p>While in U-Boot the default ethernet device is the lower jack, the installer is
only able to use the upper, so replug the ethernet cable to the upper
receptacle.</p>
<p>Go through the installation, and before rebooting do the following:
Select "Change debconf priority" and set it to "low". Then "Download installer components" and check "mtd-modules-3.16.0-4-armmp-di". After that "Execute a shell" and do:</p>
<div class="highlight"><pre><span></span><code><span class="gp"># </span><span class="nb">echo</span><span class="w"> </span><span class="s2">"The following is dangerous, see Note below!"</span>
<span class="gp"># </span>depmod<span class="w"> </span>-a<span class="w"> </span>
<span class="gp"># </span>modprobe<span class="w"> </span>pxa3xx_nand
<span class="gp"># </span>mount<span class="w"> </span>--bind<span class="w"> </span>/proc<span class="w"> </span>/target/proc
<span class="gp"># </span>chroot<span class="w"> </span>/target
<span class="gp"># </span>cat<span class="w"> </span>>><span class="w"> </span>/etc/flash-kernel/db<span class="w"> </span><<<span class="w"> </span>EOF
<span class="go">Machine: NETGEAR ReadyNAS 104</span>
<span class="go">DTB-Id: armada-370-netgear-rn104.dtb</span>
<span class="go">DTB-Append: yes</span>
<span class="go">Mtd-Kernel: uImage</span>
<span class="go">Mtd-Initrd: minirootfs</span>
<span class="go">U-Boot-Kernel-Address: 0x04000000</span>
<span class="go">U-Boot-Initrd-Address: 0x05000000</span>
<span class="go">Required-Packages: u-boot-tools</span>
<span class="go">EOF</span>
<span class="gp"># </span>flash-kernel
</code></pre></div>
<p>You then need to adapt the u-boot environment to pass the right root parameter
to Linux. Alternatively add <code>Bootloader-Sets-Incorrect-Root: yes</code> to
<code>/etc/flash-kernel/db</code>.</p>
<p>Note: flash-kernel as of now (flash-kernel 3.35+deb8u2 and also 3.56) doesn't
handle bad blocks correctly. This might damage your flash beyond repair!
So maybe better don't setup flash-kernel as suggested above. Use at your own
risk.</p>
<p>[1] Note this page is about a ReadyNAS 102, the pinout is identical though.</p>