Hi bodhi, 2298 of the permanently modified files are kernel modules *.ko, and 120 of them are device tree blobs *.dtb. The remaining 28 ones are: zcat /tmp/modified-files.lst.zip | egrep -v '.ko$|.dtb$' /boot/System.map-5.8.5-mvebu-370xp-tld-1 /boot/config-5.8.5-mvebu-370xp-tld-1 /boot/initrd.img-5.8.5-mvebu-370xp-tld-1 /boot/linux-5.8.5-mvebu-370xp-tld-1.patch /boot/linux-dby tme - Debian
The attachment to previous post was too large. Here a compressed version.by tme - Debian
Hi bodhi, Confirmed. This worked: sudo su - apt install -y qemu lsblk | egrep -v '^loop' mount /dev/sdb1 /mnt cd /mnt/boot tar xf /tmp/linux-5.8.5-mvebu-370xp-tld-1-bodhi.tar.bz2 tar xf linux-dtb-5.8.5-mvebu-370xp-tld-1.tar chroot .. bin/bash dpkg -i /boot/linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb Selecting previously unselected package linux-image-5.8.5-mvebu-3by tme - Debian
Hi bodhi, Test A: Boot with an Ethernet connection from 4 GB USB stick from Innodisk. First boot: Shutdown after 62 seconds. Last serial console output: [ 5.091676][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 is missing. Second boot: Shutdown after 62 seconds. Last serial console output: [ 5.093709][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 isby tme - Debian
Hi bodhi, Quote dpkg -i linux-image-5.8.5-mvebu-370xp-tld-1_1.0_armhf.deb That was an important step that you did not do. Thanks! I consciously postphoned this step until after the first boot (which never finished), convinced that this step on the PC would affect the PC and not the USB stick mounted on /mnt. I need to do a 'chroot' and activate 'qemu' before doing thiby tme - Debian
Hi bodhi, Quote Let me take a look at the boot logs to see why it was reset at 54 seconds. Thanks! Here are my thoughts: The last line on the serial console before the box shuts down is [ 5.695371][ T1] mdio_bus d0072004.mdio-mii: MDIO device at address 1 is missing. MDIO is about managing the Ethernet connection(s). I will check if the presence or absence of a Ethernet link duringby tme - Debian
Hi bodhi, Quote Get the mainline kernel source tree for 5.8.5 from kernel.org (or clone Linux GitHub). Apply the patch. Copy the config to the source tree. And build. I did some days ago and ended up with these results: scripts/config --disable DEBUG_INFO make clean make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j $(nproc) bindeb-pkg ls -lF .. total 32836 drwxrwxr-x 25 tme tmeby tme - Debian
Hi bodhi, Quote [ 27.104494] systemd-udevd[1710]: Could not generate persistent MAC address for eth0: No such file or directory udev name has changed to systemd-udev, but there is no systemd involved in running udev under sysvinit. Thanks! I don't want to dig deeper into this right now. Quote you can set the env ethaddr to the same MAC address as eth1addr in u-boot We agree, bby tme - Debian
Hi whitepawn, Quote Trond, may ask you to try stress command on your box with front usb attached? I did: apt install -y stress stress -cpu 1 -io 2 -vm 1 -hdd 1 --timeout 10s The USB driver reset and disconnected, but no kernel panic. The 'etx4' file system ended up in a bad state, so this test is destructive and the file system must be rebuild from scratch. Output attached inby tme - Debian
Hi bodhi, I am puzzeld by what code in the Linux 5.8.5 source tree that (see my previous post) prints [ 27.104494] systemd-udevd[1710]: Could not generate persistent MAC address for eth0: No such file or directory in the 'dmesg' log, since both these commands terminate silently: find ~/kernel/linux-5.8.5 -type f -exec grep -nHo 'systemd-udevd' {} \; find ~/kernel/lby tme - Debian
Quotetme I'm running 'systemd' rather than 'init'. No, I'm not: [ 5.792411] Run /init as init process [ 5.796597] with arguments: [ 5.796604] /init [ 5.796608] with environment: [ 5.796613] HOME=/ [ 5.796616] TERM=linux [ 5.796621] reason=normal [ 5.796624] bdtype=rn102 So even '/init' usesby tme - Debian
Hi bodhi, Spot on. Success! Thank you very much! Pasting commands both on the terminal and to my test report is clearly too much for my intellectual capacity. I have edited my latest post above and added the missing step to the last code frame. Plugged the USB-stick into RN102's front connector again and hit the power button. Logged in with 'ssh root@debian.local' when boot cby tme - Debian
Hi bodhi, I have tried to installed your Debian 5.2.9 root file system and your Linux 5.8.5 kernel from scratch on my Netgear ReadyNAS RT102. I did not succeed, but thank you very much for your efforts! For reference, this is what I did on my PC: sudo su - cd /tmp md5sum * ffe6bb6a1d591b06be1f3a55273bc236 armada-370-netgear-rn102.dtb ffa864878dd797241c0bea05d563239a Debian-5.2.9-mvby tme - Debian
Hi bodhi, Being able to build my own kernel, and boot it, would make it much easier to assist you in supporting the RT102. I solved the 'armel/armhf' issue above, but failed to make my kernel run. After u-boot wispers "Starting kernel ...", nothing happens. The error message about unrecognized/unsupported processor variant is replaced by silence. Hardly a step forward. Iby tme - Debian
Hi bodhi, A minor suggestion for your '/etc/rc.local' script: If you use -x rather than -f when testing for '/root/set_persistent_mac_address', one may disable and exnable this script with 'chmod -x' and 'chmod -x'. Nifty? EDIT: Fixed typo. Substituted -e with -x. Regards, Trond Melenby tme - Debian
Thanks bodhi, I have edited my post above and added the missing modification of the 'fw_env.config' file. QuoteSince your box use eth1 (unlike most other boxes), then script set_persistent_mac_address should use ethaddr1 and eth1. And also your /etc/network/interfaces needs updated, too. It is default to eth0 in the rootfs (this was the reason for the dhcp to go back to eth0 in yoby tme - Debian
Hi bodhi, Quotebodhi Looks like you have missed the /etc/fw_env.config new definition. Thanks a lot! I trusted you would spot the issue at a glance. Now it works. I will edit my previous post to include the 'fw_env.config' update. There still is a run away CR <13> character, but I recon we can live with that: cat /etc/fw_env.config # MTD device name Device offsetby tme - Debian
Hi bodhi, Following up this post, I have performed a fresh install of your latest Debian version, but with Linux kernel 4.20.6 and the modified device tree for the ReadyNAS RN102. Complete procedure follows mainly for my own later reference. On my Ubuntu 20.04 laptop, I downloaded the input files to /tmp/bodhi. The md5 sums were: /tmp/bodhi md5sum * ffe6bb6a1d591b06be1f3a55273bc236 arby tme - Debian
Hei bodhi, I have two RN102 units now and can thus test alternative solutions against each other for performance or other behavior. I will keep the vendor's firmware on the second one for some time to be able to compare Debian against stock. Later I will be able to compare Debian against Debian. I notice that the stock kernel uses the u-boot environment variable 'eth1addr' foby tme - Debian
Hi bodhi, I think 'keep' as 'defualt-state' in the dts-file is a good thing if is to be interpreted as "read the current state of this LED and align the driver's shadow variable with it", but maybe 'keep' means something else? 'keep' as 'default-state' cannot be blamed here because the Backup LED, which 'default-state'by tme - Debian
Hi bodhi, Reunited with my box. I can confirm whitepawn's findings on the mtd partitions. My test session listing is attached as a file. I wondered if u-boot would find a USB-stick on the USB3 connectors at the back if the stick was USB2, so I tried this. It made no difference. A working real-time clock to wake up the NAS after a power failure is important, since the unit does not bby tme - Debian
Thanks, bodhi, for your swift and detailed reply! I will, but give me a few days. I'm away from my box. Regards, Trond Melenby tme - Debian
Hi bodhi and whitepawn, I have for some time now wanted to migrate my home file servers from Netgear Stora (I use 3 of them) running Debian to Netgear ReadyNAS RN102. Following the instructions and hints above, I yesterday successfully installed Debian on my RN102. Thank you very much for your great efforts! I look forward to test any new kernels, root file systems or utilities targeted for tby tme - Debian
I'm sorry for misleading you, bodhi. This hex dump may be slightly more useful: root@stabburet:~# cat /dev/input/event0 > /tmp/events ^C root@stabburet:~# xxd /tmp/events 0000000: 776b 2c59 9a85 0b00 0100 7400 0100 0000 wk,Y......t..... 0000010: 776b 2c59 9a85 0b00 0000 0000 0000 0000 wk,Y............ 0000020: 7c6b 2c59 1b6b 0500 0100 7400 0000 0000 |k,Y.k....t..... 0000030: 7by tme - Debian
Thanks bodhi, for your swift response! I intalled 'esekeyd' and modified '/etc/default/esekeyd' to get it running at boot, and added the "dummy" actions: root@stabburet:~# diff /etc/default/esekeyd.orig /etc/default/esekeyd 4c4 < START_ESEKEYD=false --- > START_ESEKEYD=true root@stabburet:~# cat /etc/esekeyd.conf POWER:/usr/bin/logger -s -i &quby tme - Debian
Thanks to the information available at this site, and to the great support of 'bodhi', I have successfully upgraded all my 3 Neatgear Stora NAS boxes to the latest versions of u-boot, u-boot environment, LInux and Debian. They are all running fine. Thanks, again! There is one feature in paricular of the original stock Netgear firmware that I miss. From the user guide: "To correcby tme - Debian
Hi bodhi, Thanks for following up, and thanks again for your effort and instructions! I have now also successfully updated the default u-boot environment to the latest version. I'm happy to be able to add disks to the Netgear Stora NAS without having to worry about devices being renamed. Thanks! I used the binaries included in your tar-ball U-Boot flashing utilities, but afterwardsby tme - uBoot
Hi bodhi, I have successfully installed the latest u-boot on my Netgear Stora, and have sucessfully booted debian 8 wheezy from a 2GB industrial grade USB stick from HGST. Thanks a lot for your effort and instructions! However, repeating the same procedure using a 8GB commercial grade USB stick from Patriot, u-boot fails loading uInitrd. I find this rather strange since u-boot loads uImageby tme - uBoot