Bodhi, I think this problem has been solved for now. I have created a fresh rootfs with this Buster version: https://forum.doozan.com/read.php?2,16044 for the pogoplug. But this time after the update there was no loss of Ethernet anymore. I think the problems I encountered were caused because of inconsistencies due to different times from the system I run the update from, the time value wby hacksome - Debian
Bodhi, QuoteBodhi Plug in a USB thumb drive, and at serial console prompt, usb reset ext2ls usb 0:1 / If you can see the USB drive top directory listing from these commands, then it is OK to use USB rootfs. And that is my example above for: I tried these commands on the serial console, but did not get any response that looked like a USB device being recognized. I am not certainby hacksome - Debian
Bodhi, SATA boot is working! I did find the env changes to boot from a standard SATA disk automatically! The disk of course must be properly populated with a rootfs configured for this box. But that´s not difficult to do. I used Debian Stretch. (4.4.54-oxnas-tld-1) this time. But using Debian Buster instead should be similar I guess. These are the environment changes I made: seteby hacksome - Debian
Bodhi, I finally found a way to revert to stock u-boot. It took me quite some time to figure out the steps and most of all: to verify as much as possible to prevent messing up things more then they already were. The biggest hurdle was that I could not find anything about images being encoded (some seem to call it wrapped) to be able to use error correcting features of NAND memory or to beby hacksome - Debian
Bodhi, QuoteBodhi OK. So to avoid trying to reinvent some wheel here. What we should do is to go back to booting this KD20 from the HDD. Using your tarball. - And then trying to set envs in serial console, and save them in serial console. It might work. That is the problem I already ran into earlier. I am able to modify the envs that are used by the KD20 uboot. You can see those in theby hacksome - Debian
Bohdi, no glory, trying the original script: To create a new sata disk I only used dd if=./u-boot-spl.bin of=/dev/sdb bs=512 seek=34 to replace de existing spl image to the disk. (replaced stage1.wrapper with u-boot-spl.bin) I did not modify the existing rootfs because all the files needed were already present in the proper location. Exept the following files that I added to theby hacksome - Debian
QuoteBohdi Is there a reason why you did not use the original disk_create.sh ? Everything is relative of what one uses as a reference. I used the images from the archive KD20_sata_boot.tar.gz with the u-boot configured for the KD20. In this archive is also a disk_create file. Not disk_create.sh, but that´s just a name. So in my perception I used the ¨original¨ disk_create script.by hacksome - Debian
QuoteEchowarrior108 owncloud was also nextcloud nextcloud is a fork of owncloud. I do not know the details, but from reading about the 2 I got the impression that nextcloud uses even more resources than owncloud. And I had read about using older versions of owncloud on a Pogoplug in this forum and the wiki. About: QuoteEchowarrior108 This version of ownCloud is not compatible with PHPby hacksome - Debian
Bohdi, output from requested commands: root@debian:~# uname -a Linux debian 4.4.54-oxnas-tld-1 #2 SMP PREEMPT Sat Mar 18 23:09:58 PDT 2017 armv6l GNU/Linux root@debian:~# e2label /dev/sda1 rootfs root@debian:~# mount /dev/sda1 on / type ext3 (rw,noatime,errors=remount-ro,data=ordered) devtmpfs on /dev type devtmpfs (rw,relatime,size=125316k,nr_inodes=31329,mode=755) sysfs onby hacksome - Debian
Bohdi, I got to know I did no pick the most easy device. I have a PogoplugPro and that´s running fine, although i still have to resolve the systemd issue in combination with upgrading a fresh Buster install;) But this complexity is just one of the things that drive me because I am convinced that what I want to do can be done. Although it might not be easy. Because all the frustrating evby hacksome - Debian
Bodhi, I have used this archive: https://www.dropbox.com/s/82t5pfnybvacr3b/KD20_sata_boot.tar.gz?dl=0 from this thread: https://forum.doozan.com/read.php?2,17649,page=4 In this archive there is a only one folder: oxnas_sata_boot. In that folder are 3 files: disk_create stage1.wrapped u-boot.wrapped sizes: ls -larth *.wrapped: -rwxr-xr-x 1 john john 8,1K jan 21 2015 stage1.wrappeby hacksome - Debian
Bodhi, maybe I was not specific enough. I have no problem creating a direct sata boot disk and populate the rootfs with a debian version. For now I use Debian Stretch 4.4.54. When I start this sata boot disk I get this U-boot screen on the serial TTY. Stage-1 Bootloader 2015-01.21-21:48:56 Attempting to set PLLA to 800MHz ... plla_ctrl0 : 0x0000030A plla_ctrl1 : 0x00400000 plla_ctby hacksome - Debian
Bodhi, I created the direct SATA boot with the KD20 'stage1.wrapped' and 'u-boot.wrapped' dd´ d those to the disk and i got a working U-boot. I populated a rootfs with Debian-4.4.54-oxnas-tld-1-rootfs-bodhi.tar.bz2 (Stretch). With KD20.dtb appended to uImage. However, I could not figure out what u-boot environment changes were needed to actually boot from the disk. prby hacksome - Debian
Bodhi, I would like to roll back what I did and option 3 seems the most easy option to me, however for some reason I cannot establish a tftp connection with the U-boot available with direct boot from SATA. It looks as if no Ethernet device is detected. When I set various addresses: serverip, ipaddr, gatewayip etc. Only the ipaddr is retained when saved and rebooted. Both serverip and other cby hacksome - Debian
Bohdi, I am impressed with your swift response! I also see that most of my assumptions were OK. What I missed completely is that the OXNAS U-boot is actually not used at all on this box. I guess I completely misinterpreted your advice to ´Bastler´ and specifically this part at:https://forum.doozan.com/read.php?3,16469,page=2 3rd last message where I read this: > Remember, thisby hacksome - Debian
I was trying to get a KD20 OMNINAS to boot from USB. At first I managed to use tftp upload of uImage with kd20.dtb appended and uInitrd I could mostly reproduce the events as described in: https://forum.doozan.com/read.php?3,16469,page=2 until I could boot from sata and from USB when uImage and UInitrd were loaded with tftp. To flash U-boot I booted from USB, downloaded the uboot.2015.1by hacksome - Debian
Bodhi, I did a new install without running apt update before I ran ap install systemd That produced similar meassages about packages to be installed, however it could not execute properly because of : FATAL -> Failed to fork. debconf: apt-extracttemplates failed: No such file or directory and: W: Could not open file /var/log/apt/eipp.log.xz - open (12: Cannot allocate memory)by hacksome - Debian
Bodhi, I did a fresh install (Pogoplug), but things were very different than what I expected. But I also think I used a different chain of steps. e.g. update before reinstal of systemd. This is my log of the steps I used: Extracted package to drive/rootfs with: tar -xjf Debian-4.14.180-oxnas-tld-1-rootfs-bodhi.tar.bz2 skipped step 4 because I have a Pogopro V3 (with PCI and WLAN) skipby hacksome - Debian
Bodhi, I am not really sure. I have to verify this. When I was trying to install OC10 on Buster I skipped the upgrade due to the loss of ethernet. But later on I discovered that systemd was not properly installed or functioning. In between I created a new and fresh Buster image, I would expect I did take care to have a properly functioning systemd, but I am not certain about this. Curreby hacksome - Debian
Bodhi, oops, it was not so obvious, although I mentioned oxnas in the message text. modified the topic titles to be more specific.by hacksome - Debian
Bodhi, I updated the post as requested. I did not add details yet that showed up as complaint in the apache logs. Apache is unable to resolve hostnames or something like that. But that does not prevent it from running properly. I will add that later. done During all this I found out that at my system the systemd service was not installed properly for some reason. I hope to have this solvby hacksome - Debian
I installed the last Debian Buster oxnas release, that run perfectly. But then ran update, about 50 files could be upgraded. I ran the upgrade and after that the eth0 if was not initialized . I found a work around: adding: ifconfig eth0 up /etc/init.d/networking restart to /etc/rc.local so the system runs OK now, but I do not expect that this is supposed to be. cat /etc/network/inteby hacksome - Debian
@gravelrash: you were right after all I think. I figured it out myself because after some trials with uploading pictures the error messages re-appeared and only a few pictures were transferred. Searching for clues I found leads that also pointed to systemd. Checking its availability showed that sysvinit was active and systemd showed: other. So I reinstalled systemd. Then both sysvinit and sysby hacksome - Debian
Thanks for suggestion, but systemd was already on the newest version..... Another thing I noticed: after a new boot I kept OC running for a few hrs and uploaded an deleted some files. I checked the memory usage during activities, but those were not worrying. (not much memory left, but no heavy use of swapping either) I had noticed similar behavior before with a previous install. Similar TTYby hacksome - Debian
OK I was maybe a little too fast with the above. I see now at the TTY output a lot of worrying messages and the system became unresponsive. I had this before when I had added the local storage to OC but forgotten to adjust the permissions properly. I thought that was the cause of this kind of error messages but apparently that is not so... This is what is showing up on the TTY output:by hacksome - Debian
I did managed to get Owncloud10 running on a 128Mb Pogoplug V3 OXNAS with Debian 10 installed.... Based on a proper quality microUSB card (32GB) formatted with one 6GB ext4 primary partition labeled ¨rootfs¨ and remaining data space ext4 formatted labeled ¨data¨ Create or update system to Debian Buster as described here: https://forum.doozan.com/read.php?2,16044 Ensure that systemd isby hacksome - Debian
I have refreshed the procedure how to create a sata rescue disk. I have checked it only using an sata-SD adapter. It works with a Samsung EVO 32GB Sd and a 16Gb Kingston SD. Steps to follow to create a sata rescue disk for a Pogo Pro or Pogo Classic. You need a sata disk. All data on it will be destroyed. A sata disk can be: - regular sata disk 2.5 inch or 3.5 inch. However for the 3.5 inby hacksome - uBoot
I was kind of trying to enhance (and understand the details) of youxiaojie's thread. I was also wondering why the SATA disk did not boot properly. And I think I found the problem, or at least part of it: Also with the current (restored) Uboot in NAND when the the SATA disk (with the special code in the first sectors) is installed it will not boot properly. The log shows these lines:by hacksome - uBoot
Perfect! Even the warning about the specially prepared disk. Initially I did not notice your warning properly. I booted as you suggested. It did boot the kernel from the thumb drive. I SSH´d into the box. I flashed the new uboot (piece of cake because all the files were already on the thumb drive). Then, without detaching the sata drive it rebooted but got stuck in a similar way (busyboxby hacksome - uBoot