Squatter

I built Armbian fresh using sid this time as I have had zero problems with "Bookworm testing". The new SD build still shows a severely performance-affected eMMC so I am pretending it doesn't exist anymore. When a new fast flash drive arrives, I will use nand-sata-install with that. I did note that with a bootable SD and a bootable eMMC, while nand-sata-install did copy stuff over, it would boot from the SD but mount the eMMC /boot directory. Kernel upgrades would upgrade the eMMC mounted root but a reboot used the SD card version. I will look to see if a manual change to the mounted root fixes that. For the record, apart from the 1st 6 months in 2019 trying to use the vendor-supplied Linux (it was seriously flawed), I have been running Armbian successfully ever since. Any errors being of my own making. Thank you to the developers.

My Opi3 has been running armbian for over 2 years (edge kernels & usually fully up-to-date). I have been using eMMC & I noticed an apparent slowdown about 6 months ago. As it performs cron-based tasks and is a stats collector, this performance was not noticable but doing a manual BIG dist-upgrade, it seems to take forever (20 minutes to do what should be under 5 minutes). If I run "mmc extcsd read /dev/mmcblk1", the results tell me that the eMMC is at least 90% used whatever that really means. Is this a sign of imminent failure ? hdparm shows read results of 17 MB/s which is actually slower than my alternative SD card boot device and nearly 1/10th the result of a mounted flash disk (146 MB/s). Am I right in assuming that the eMMC is really at the end of its life and I should look to move to an alternative primary storage for boot etc. I do all of my "work" on a mounted flash drive so data loss is not an issue. Is the way to go as follows : minimal boot from the eMMC or an SD card which switches ALL further OS work to the flash drive How does one formally disable the eMMC storage entirely ? Thanks

Thank you Martin. 30 seconds hard work & wlan0 is fine. cpu seems to be running at the full 1.8GHz v. the throttled 1.5GHz of the OPi image. I can confirm armbian WIP cpu benchmark ~20% faster over OPi image which seems to be consistent with the throttling. And for some reason, the OPi image benchmark that I used only saw 3 of the 4 cpus so parallel performance is even higher. Once over the wlan & HDMI hurdles, I now have a fully kitted out lxde environment accessible by rdp plus a full web development environment. I had a minimum set of criteria re. performance & capability & all have been exceeded as I never planned to use HDMI anyway, nor do I have any immediate plans for PCiE or the IO pins. I think I am now over comparing what the OPi image offered v. the armbian WIP. The only glitches I encountered were related to rdp which appears to have stumbled universally on Ubuntu 18.04.2. And some strange intermittent behaviour re. wlan losing nameservers (resolv.conf not being populated) after a reboot ... trying to pin that one down. But these are software not hardware issues. I will just press on assuming that everything I need to work just works ... as it does so far. After 29 years in the unix sysadmin/builder role world (on and off) its now just a hobby.

Thanks Igor. I get the drift. I doubt I will bother asking any more questions.

Martin, Cable has arrived. I booted the new "8 May" image & it came up perfectly on the serial. Nothing on the HDMI. No wireless even with pre-configured /etc/network/interfaces. So borrowed ethernet cable (no more router slots) & remote ssh came up fine. Log files are SO MUCH cleaner than "original Orange Pi image" logs. And "/proc/cpuinfo " almost seems sensible now. Wireless was easy on original image but nothing on armbian. So this is the first time I have actually seen "armbian" so go easy on me. A deceptive difference is the lights on the board are different ... only one red light compared to one red and one green. I don't care really as long as it works ... except wireless. ifconfig produces no sign of wlan. Also xrdp does not work out of the box. More later. Any suggestions welcome re. HDMI & wireless. Back to beer brewing.

OK, I tried the older image as above & same result. On a successful "boot" (my semantics) two red lights on the OPi3 come on then one switches to green (the one next to the power input while the one above the SD card slot always stays red). In all of my armbian cases, there is no switch to green. I do not have a USB-TTL dongle. The best I can do at the moment is mount the SD (from a non-armbian OS system) & see if any log files have changed in /var/log ... no change on any attempt so far. I have a feeling I should never have copied the OrangePi-supplied image to the eMMC, which I did before I even started with armbian. It may have done something that anyone in the armbian world would never do or expect. I have attached the results of "fdisk -l" after SD Formatter, after Etching image & after unsuccessful boot attempt. This may suggest something to you. fdisk-l.txt

I am not sure I can run armbian-config successfully as I can not even boot armbian yet ... this is why I am on this forum. Maybe armbian-config will still run from the mounted armbian on the SD card ... I will investigate. All I know is that 3 different dated versions of the Opi3 nightly will not boot from the SD card for me ... the Orange Pi supplied image has no problem booting whether it is on the eMMC or an SD card. Re. the Raspberry Pi, I have only ever used OpenElec and OSMC. I quickly dispensed with OpenElec as it was a seriously cut-down Linux distribution. OSMC had a full OS underneath so I could also "do stuff" while it functioned (at the other end of the house) as my media server, TV recorder & for remote TV in my study. Sadly, support for remote X (X, xrdp & vnc) was removed about 18 months ago. But up to then, I could run a vnc or xrdp session with ease (a normal user desktop not remote Kodi). Obviously this is a design decision of OSMC and not due to broken-ness. I have never touched Raspbian. I have had the Raspberry for over 4 years & it just chugs away fairly maintenance free ... except for when the "X stuff change" broke it & a failed SD card.

I am using "Armbian_5.83.190427_Orangepi3_Ubuntu_bionic_dev_5.0.10.7z" from https://dl.armbian.com/orangepi3/nightly/ It works as you suggest if I insert an "OrangePi image" SD but not with the "Armbian Image" SD above. I was thinking maybe the Orange Pi script to transfer the OS to the eMMC does it differently compared to nand-sata-install &/or the bootblock(s) are different to what Armbian expect. I have tested the SD cards & they are official and am using Etcher on a late model laptop with an SD card slot. Where I want to get to is Armbian on the eMMC but if I so desire, insert a bootable SD which becomes the default boot device. And a normal non-bootable SD just becomes available when inserted when running the eMMC as boot device. I am sure you know how it is. You do something for the first time, thought you got it right and until it actually works, you never quite know what IS right.

I am sorry I am a bit slow but I think I am not understanding something very important. I believe I have copied the latest Armbian image to the SD card correctly & error-free. I can mount it perfectly & view everything. The working system on my eMMC is based on the Orange Pi supplied uboot version of Ubuntu (updated to the latest 18.04.2 but with the 4.9 kernel). I used the Orange Pi supplied script to do the copy to eMMC. If I burn the original Orange Pi supplied image to the SD, it boots happily from the SD card ... the eMMC is clearly mmcblkp0 & the SD mmcblkp1. If I copy the Armbian image, I get nothing when the SD is inserted and booted. So there is obviously some tweak that is required in the u-boot way of doing things to facilitate a successful Armbian boot from the SD. I guess there is a setting that says "if an SD card is inserted & u-boot exists on it, boot it". I could be wrong. At this point, I am running the original Orange Pi image off the SD so I can image my working eMMC system to a USB-connected drive AND even dd the Armbian image onto the eMMC storage. I am assuming I would need to tweak that Armbian image. Any guidance appreciated.

OK, thanks for all the background info. I am unlikely to be a kernel tweaker so will just sit back & press on with the Orange Pi in a corner with me accessing it like a normal Linux computer via xrdp. I will try to make myself ignore the voluminous info dumped into the log files as it does not seem to affect anything I do. And ignore the fact lshw says 3 of the cpus are disabled and that the cpu frequency is 1.5 GHz (not 1.8 GHz). Maybe I should re-compile lshw myself. I did compile the old "byte-unixbench" to run on the OPi, my Raspberry Pi 2 and my 15 year-old single core 1.6GHz laptop running Lubuntu. Apart from the benchmark only reporting 3 cpus on the OPi, I am satisfied that apart from close figures on the file copy tests, the OPi did exceed the other 2 systems. The only loss was the "process creation" test ... to the laptop (an x86 1.6GHz 32-bit Celeron). Nevertheless sufficient enough for me to assign the laptop to the dump, although it deserves a medal for what it has been through.

Many thanks. That pretty much explains it. The only thing I can add is that the image when burnt to SD has no flags set. Turning boot flag on also did nothing, where nothing in all cases, means absolutely no action on the monitor & the LED (near the power input) that usually goes green on a working system, stays red. I am not a Linux kernel guru although I was once a moderate FreeBSD kernel tweaker. So I guess I will stick to the upgraded but working system based on the 4.9 (yes, my memory got that wrong) kernel and I will touch base with the Armbian nightly regularly to see if the boot issue resolves. It is not too hard to do this as my working system is on the eMMC storage ... shutdown, remove power, insert SD, reboot ... if fails, turn off power, remove SD, reboot, working system again ... less than 5 minutes to test. The best I can do to help is to tweak some of the settings in /boot if I knew what to tweak. Yes, I did know that this might not be all plain sailing. I already know I can run a useful system but this WAS a hobby purchase. I just hope the Orange Pi 3 OS gets there before the Raspberry Pi 4 comes out & blows it away ... 9 to 12 months away.

I have had a Raspberry Pi for 3 years now with no major issues. I use a 15 year-old laptop with an unusable display to run as a Linux test/training/utility machine. It is almost dead so I decided to test myself with an Orange Pi as a low power replacement. I have installed the Orange Pi supplied Ubuntu image (version 16.04) & successfully upgraded it to version 18.04 (with a few hacks to make that process work). There are tons of syslog error messages due to the well-known dev nature of the kernel but for my purposes, the basic functions work. However the kernel is a uboot kernel and stuck at Linux 4.19 with an unknown upgrade cycle through the Orange Pi servers. I have moved the functioning Ubuntu above to the eMMC storage and am now trying SD card images burnt from https://dl.armbian.com/orangepi3 but they just will not boot. I have dd-ed (which has always worked for me) & even used etcher but no change. I do notice the contents of the /boot directory are noticeably different from the supplied Orange Pi images (ie no uboot stuff for instance). Am I missing something ?