tkaiser

A while ago we added some logic to set LINUXFAMILY=sunxi in /etc/armbian-release and this breaks completely the IRQ affinity settings in /etc/init.d/armhwinfo (prepare_board function). Sunxi boards upgrading to 5.35 get slower with some use cases unless a fix in 5.36 is provided (though I've no idea how the fix should look like) It seems board support packages on apt.armbian.com have been built a few days ago not containing latest fixes. Is this possible?

Just why? Our next branch is at 4.13 already and the old dev branch has been trashed few hours ago: https://github.com/armbian/build/commit/376fcd218689186ae23ba7baa2db0ce0d65308e5 And when you tomorrow update your installation from beta repo it will break anyway. There exist not that many reasons to choose dev branch (unless you want to improve Armbian of course and provide constructive feedback)

Thanks for confirming. As @zador.blood.stained already explained without taking a lot of care it's not possible to 'crossgrade' from a legacy to a next (and especially a dev) image. We tried to support this in the past but stopped since we're not able to support this level of complexity. The 'google site search' when fed with 'only one cpu core' will answer the question why different boot stuff is needed...

I know since that's what's to be expected and tested. But I was asking for something else: whether the 5.35 next image for Orange Pi One from last night boots correctly or not. That's all I'm interested in and I thought I could save some time asking users for help instead of searching for the board, downloading the image...

Does this image boot with 1 or 4 CPU cores?

Neither/nor, it's you trying to combine legacy u-boot with next or dev kernel. Expected result: Only one CPU core active. Use -f with dpkg to get linux-u-boot-orangepione-default out of your way and you're done (or better start from scratch with a fresh next image -- it always feels strange reading threads popping up discussing issues that are solved since ages)

Fine with me. Just thought about this one here but this can also be fixed later...

Yes, that's all that currently is supposed to work when source fs is already btrfs. So this is by design and changing the script to do something else will fail. While I really don't know why you want to transfer the rootfs from SD card to an pendrive (since a good SD card and flashmemory plugin active will also be sufficient) in case you want to use an SSD you need to take care that you partition it before otherwise OMV won't allow you to use the SSD for data (this is all very off-topic here but anyway please read through these instructions)

IMO no. The recovery procedure is basically the same and now it's even more easy since you simply download an Armbian image, boot from SD card and modifiy the first partition of your eMMC as described above. Then shutdown, remove SD card, boot from eMMC, done.

Maybe @bozden can help here? IMO it's really important that if 3rd parties try to directly link to Armbian images (and not the download pages) that they use those generic links like 'Ubuntu_xenial_default.7z' which will be resolved automagically to most recent OS image in the background. It's sad to see outdated images being spread...

There's no need to purge anything since more software installed does NOT make anything slower except package updates for obvious reasons. If you look at the download location there are two experimental images: https://dl.armbian.com/orangepipc2/ -- instead of choosing the desktop one and fiddling around with 'apt purge' why not using the server variant in the first place?

Good point I almost forgot about since this is set by default with OMV already (tested on day 1 when I started with OMV back in April -- OMV uses some internal preferences which then get fed into the daemon's config files automagically): root@odroidxu4:~# testparm 2>/dev/null | grep sendfile use sendfile = Yes So I tested the opposite now with Armbian/OMV by setting 'use sendfile = no' in OMV's "/config/services/smb/extraoptions", verified with testparm and as expected read performance drops a lot (directory enumeration too) while write performance slightly increases: So yes, 'use sendfile = yes' is important even with beefy hardware (I did a quick check also with performance governor but numbers are close to identical so it's not related with cpufreq scaling and also not a true CPU bottleneck -- watched utilization with htop, everything happens on the big cores and it looks like there's still some room... unlike with A20 where usually the smbd thread is bottlenecked by the CPU core it's running on) As a comparison the 'use sendfile = yes' numbers from above again:

BTW: I tested through a variety of other OS images the last weeks/months and since some of those have been recently re-released I gave it a try again today. Just as an example how important appropriate settings are if you want to squeeze out the max out of your hardware. The following is 3 times exactly the same hardware (HC1 with same SSD as /dev/sda1, same SanDisk Extreme Plus with the OS on, same Gigabit network, same MacBook as client). It's even exactly same Debian version (latest Jessie) and also exactly identical Samba version. Why the performance differs that much is explained here in detail. The first distro tested uses an outdated 3.10 kernel, doesn't take care about IRQ affinity or any other relevant settings (except cpufreq scaling) and also uses default (AKA bad) Samba settings. The second distro is the one the first is based on. Same kernel but different cpufreq settings. Obviously also no further optimizations but here OMV has been installed with armbian-config/softy by me which explains the much better SMB write performance The 3rd is latest official OMV 3 image based on Armbian and our next kernel branch so using a rather recent 4.9 LTS kernel soon to be switched to 4.14 (tweaks explained here) Disclaimer: The dietpi and Meveric numbers were made a few weeks ago and I couldn't believe that they were that low. But today I did a quick re-test (only one run since it takes ages due to that low performance) and so I decided to publish results. Please be aware that these Samba tests were made with a MacBook running macOS as client which does not show best possible performance (for reasons see here for example -- it needs a more recent Samba version with special settings to perform optimal with macOS clients) so most probably in real-world scenarios and with Windows as clients performance differences might not be that huge and overall SMB performance higher with the non OMV images. BTW: SMB write performance with dietpi increased by 6-7 times as expected just by adding the usual 4 simple lines with some adjusted settings to smb.conf. Edit: And 'use sendfile = yes' might also make a real difference, see posts below. Won't test with dietpi again since already deleted.

Me not, I prefer the better alternative: RTL8153. Better driver support, slightly better performance, slightly lower CPU utilization.

Yep, there it is: |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M Unfortunately this kernel (and 23 other Armbian kernels) missed a bit more USB verbosity (fixed now) so with next nightly image or when you update tomorrow from beta repository there might be a little bit more in the logs. But it won't change that much since with this kernel (XHCI / USB3 host controller) the Norelsys thingie will cause problems. Might be fixed with mainline kernel (no idea, never tried) but the best you could do with Norelsys enclosures is to avoid connecting them to Linux hosts anyway or use USB2.

Ok, the chipset is UAS blacklisted (see 'usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u') There's not a single occurence of this device in the log except of [ 4.664115] usb 2-1: new full-speed USB device number 2 using xhci-hcd [ 4.671224] xhci-hcd d0058000.usb3: ERROR: unexpected setup context command completion code 0x11. [ 4.680683] usb 2-1: hub failed to enable device, error -22 But you said it's recognized when connecting to the USB2 port. But there's nothing. Anyway, this Norelsys chipset is crap, at least combined with Linux (I bought two of these things by accident few months ago -- advertised as good JMS578 -- and donated one in the meantime to UAS maintainer. But the problem according to log is not only related to UAS). I hope you are aware that the USB3-A connector is somewhat problematic? You need full force to insert jacks into receptacles otherwise SuperSpeed data lines can be troublesome...

Controller: NS1068X -- that's the problem. This thing needs UAS blacklisting so please try the following: Attach it to your EspressoBin when powered down. Boot once then reboot, then provide output from 'sudo armbianmonitor -u'. Takes you 3 minutes maximum.

This whole stuff looks interesting. My only concern is the rather outdated kernels they use (for Raspberry Pi it's 4.4.50 and for the Oranges 3.4.113 -- at least I don't like to run stuff that matters with that outdated kernels) Sorry, but when this OPi R1 is used correctly (as a little routing device without peripherals attached) it should be almost impossible to underpower this thing even with crappy USB cables and crappy phone chargers. I tested 2 years ago with undervolting an Orange Pi PC: still booted at 4.4V but then of course both HDMI and USB peripherals got in trouble (since way below the specs: HDMI allows for 4.8V – 5.3V and USB for 4.75V - 5.25V) while the camera was still working. On the R1 without HDMI and USB consumers that need 4.8V minimum (without USB peripherals also minimal consumption which helps with voltage drops) and most if not all components on board 3.3V max it shouldn't really matter how crappy you power the board. We got OPi Zero with reasonable settings below 700mW (mW and not mA) so depending on how much the RTL8152 consumes I would still assume that we're talking here about less than 2.5W peak consumption (too lazy and uninterested to measure myself)

Today something called 'zeroshell updated:2017-11-23' appeared on Orange Pi R1 download page: http://www.orangepi.org/downloadresources/ Curious I downloaded the image and had a look (still keen on either correct schematics or a correct hardware description. There's an additional led on this board next to the USB Ethernet MagJack and I still hope we can use a GPIO to toggle powering of the RTL8152 Ethernet chip in case it hangs). Guess what a surprise seeing that they use our work and rely on legacy kernel (IMO 'a bit' challenging for something with security in mind): root@orangepizero:/mnt/sda1# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT | grep sda sda 14.9G ├─sda4 ext4 2.1G /mnt/sda4 ├─sda2 iso9660 640M /mnt/sda2 ├─sda3 iso9660 640M /mnt/sda3 └─sda1 vfat 319M /mnt/sda1 root@orangepizero:/mnt/sda1# bin2fex OPIZERO.bin | grep corekeep fexc-bin: OPIZERO.bin: version: 1.2 fexc-bin: OPIZERO.bin: size: 35384 (84 sections), header value: 35384 [corekeeper] corekeeper_enabled = 1 root@orangepizero:/mnt/sda1# cat boot-slot.cmd setenv machid 1029 setenv bootm_boot_mode sec fatload mmc 0:1 0x500 slot.scr source 0x500 setenv bootargs ${CONSOLE} root=HD=${HD} rootwait panic=10 panic=10 loglevel=0 ${PARAMETERS} fatload mmc 0:1 0x43000000 OPIZERO.bin fatload mmc 0:1 0x48000000 ${SLOT}/${KERNEL}/vmlinuz-OPIZERO bootz 0x48000000 root@orangepizero:/mnt/sda1# cat slot setenv SLOT 1 setenv HD ZS-7D1C9C63_3.8.1A_1 setenv KERNEL 3.4.113-ARM-ZS setenv CONSOLE console=ttyS0,115200n8 setenv PARAMETERS quiet root@orangepizero:/mnt/sda4/_DB.001/LOG/2017/Nov/16/zeroshell# cat Administration Nov 16 20:50:12 zeroshell Administration: SUCCESS: System successfully started with Linux kernel 3.4.113-ARM-ZS and ZeroShell 3.8.1A

Which is perfectly understandable since no one right in his mind wants to combine the router role with the NAS role on the same device without at least containerization/virtualization. OPi R1 has 16MB (128Mb) SPI NOR flash, that's where OpenWrt should be installed into. Two Fast Ethernet ports for the NAS role? Stupid, better use Orange Pi Zero Plus instead.

No idea. I've one ASM1153E here but never measured consumption (only pretty unprecise and then I didn't notice differences to JMS567 or JMS578). Since the basic problem is always one USB3 SuperSpeed PHY and one SATA 3.0 PHY being active I also doubt that there are real power savings possible, Though for JMicron SATA bridges we learned recently that there exists the possibility to update/modify the firmware so maybe there are some tweaks possible. While I'm currently in direct contact with JMicron (issue here) I don't want to ask these questions now since waiting for firmware fixes that provide full SAT compliance for JMS567/JMS578.

BTW: Opi PC Plus has 8GB eMMC. Why not choosing this as target? Or was your system running from eMMC already and then you wanted to transfer the rootfs to an external USB storage device?

My last 2 cents on the issue: the tool needs more sanity checks. That something like this can happen is just sad (or the user is not aware that from now on his external USB drive has to be present forever) An 'installation' is something completely different than transferring an already installed system from A to B That being said if this transfer is started prior to execution of check_first_login.sh (the 'eMMC detected and asking user whether to install to eMMC' use case) then and only then it's IMO OK to call the transfer of the fresly installed OS to another media 'installation' If I would call something armbian-install or install-armbian then it's an Installer for Armbian (eg. a branded Etcher 2.0 allowing users to choose OS images for their device from an online catalogue and thereby even checking download integrity. Flashing to eMMC directly is unfortunately unrealistic since too many board makers simply suck due to not easily allowing FEL mode with an already populated eMMC) I've no idea why/how external (USB) storage should be called 'internal memory' But honestly I don't care any more, this thread is already screwed too much...

You need another Linux system and a card reader. Attach the card reader with SD card inserted, check output of lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,UUID Then you need to mount the 1st partition of the SD card and edit /mnt/boot/ArmbianEnv.txt and adjust there the line reading rootdev=UUID=e59363f1-765c-4660-9275-4563bb872371 and replace the part after 'UUID=' with what lsblk showed for partition of your SD card. The above example assumed that you mounted the partition to /mnt, if that differs you need to edit still the respective file (/boot/ArmbianEnv.txt on the SD card's 1st partition)

Update on HC2: Mass production will start in approx. 2 weeks. HC2 will be fully software compatible (same SoC, SATA bridge and even same schematics design except 12V power rails for a 3.5" HDD added on HC2). The hardware changes should be obvious: 12V DC-IN and much larger enclosure/heatsink to fit the size of 3.5" HDDs.