Jens Bauer

... Besides, it's probably just those people behind bot-nets that are responsible ... make sure you use SSH-keys for logins and disable password authentication.

Heh, we can't really know for sure exactly what happened, but there's a pretty good chance that it's not all fantasy. We know it's definitely technically possible to do this - and I'd say it's likely that it happened (if a large company says 'minor security breach', it's likely not just minor...) I kept thinking through reading the article ... why didn't they hide between the PCB layers ... and 3/4 through the articles that was actually mentioned as well. But the next thing would likely be to implement such junk inside CPUs or other chips. Intel-based devices are just very interesting, because they're mainstream and they're everywhere. ARM is also widely spread by now - this makes the ARM architecture a target. Maybe this won't happen through the CPU itself, but "bad RAM" would likely be the most likely way it would be implemented. -So now CPU vendors need a way to verify that the RAM is not modifying its contents on its own... Security by obscurity might not be so bad after all... Using a good old Z80, which noone expects in a modern computer, could protect against such attacks.

Did you read about this security hack ? (Bloomberg)

I tried posting yesterday, but when I clicked 'submit reply', the forum web-site was gone and so was everything I typed. :/ I can't reconstruct my post, but I gave an example on how little is actually needed; fortunately, I had that in my copy-and-paste buffer, so here it is: # Set boot arguments: setenv bootargs 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk1p1 rootfstype=ext4 rootwait loglevel=1' # load kernel file 'boot/image' to RAM at address 0x5000000: ext4load mmc 0:1 0x5000000 boot/image # load fdt file to RAM at address 0x4f00000: ext4load mmc 0:1 0x4f00000 boot/dtb/marvell/armada-3720-community.dtb # execute kernel in RAM: booti 0x5000000 - 0x4f00000 -Actually 'loglevel=1' is not strictly necessary, but there's no reason to be impolite. The above will only boot from partition 1 of the micro-SD card, but it's so short that it gives a fairly easy overview (in commands) of what's basically going on. The 'bootargs' environment variable is special; it's actually read by the Linux kernel. Anyway, I gave another example on how the environment variables could be added back in, in order to make it more readable with the stuff you might want to change at the top: setenv iface mmc; setenv dev 0:1; setenv root '/dev/mmcblk1p1' setenv image_name 'boot/image' setenv fdt_name 'boot/dtb/marvell/armada-3720-community.dtb' setenv kernel_addr 0x5000000; setenv fdt_addr 0x4f00000 setenv console 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000' setenv bootargs "$console root=$root rootfstype=ext4 rootwait loglevel=1" ext4load $iface $dev $kernel_addr $image_name ext4load $iface $dev $fdt_addr $fdt_name booti $kernel_addr - $fdt_addr -As you see, it's a lot easier to see what's going on if adding environment variables with descriptive names. The above is basically how Armbian boots. Armbian's boot, however, also loads a script-file from the boot-device called 'boot/boot.scr', which first imports environment variables from a file called 'boot/armbianEnv.txt'. This can be both helpful and confusing. Helpful because it makes things work quickly and easily. Confusing if you're trying to change something from your boot-prompt, because you'll keep ending up booting from the same device. Armbian's boot sequence tries to find a bootable device by first probing the SD-card and checking if there's a kernel available there. If not, then it continues to USB. It also supports netboot. This is ideal for someone who does not want to wear out the SD-card slot (they're very fragile, because board vendors very much like to save 3 cents on picking the worst type they can find!) We can also take the load_script environment variable from a few posts earlier ... setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD"; setenv boot_interface mmc; else echo "... booting from USB"; usb start; setenv boot_interface usb; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' .... and expand it and remove the semicolons, so it's a little easier to read ... if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD" setenv boot_interface mmc else echo "... booting from USB" usb start setenv boot_interface usb fi if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr source fi ... then we can add a few modifications to support SATA-boot ... setenv script "boot/boot.scr" if test -e mmc 0:1 $script; then setenv devname SD setenv boot_interface mmc else usb start if test -e usb 0:1 $script; then setenv devname USB setenv boot_interface usb else scsi scan scsi dev 0:1 setenv devname SATA setenv boot_interface scsi fi fi if test -e $boot_interface 0:1 $script; then echo "... booting from $devname" ext4load $boot_interface 0:1 0x00800000 $script source fi ... and finally wrap it back up in one line ... setenv load_script 'setenv script "boot/boot.scr"; if test -e mmc 0:1 $script; then setenv devname SD; setenv boot_interface mmc; else usb start; if test -e usb 0:1 $script; then; setenv devname USB; setenv boot_interface usb; else scsi scan; scsi dev 0:1; setenv devname SATA; setenv boot_interface scsi; fi; fi; if test -e $boot_interface 0:1 $script; then echo "... booting from $devname"; ext4load $boot_interface 0:1 0x00800000 $script; source; fi' ... which is basically what I use for booting from SATA (except from I do not attempt to boot from USB, since I often have my SD-card attached without wanting to boot from it.

I forgot to say that it's on purpose there is no parameter for 'setenv extra_params', because this will 'unset' the variable. One more thing: If you want information about what a command does, try typing this inside Uboot: help booti help ext4ls

I have not seen this string configuration before, it may be the newest way that Armbian starts up - or it may be a default setup for Uboot. It's always a good idea to explore a little before making any changes. The 'for' command iterates through a list of words/strings. First you want to know what's inside "boot_targets" and boot_prefixes... printenv boot_targets boot_prefixes If boot_targets holds a valid list (I'd expect something like 3 words), then take each of those words and supply as parameter for printenv, but prefix them with 'bootcmd_'. Eg. if a string is 'usb' then prefix it with 'bootcmd_usb' because it looks to me like inside the bootcmd, it says 'bootcmd_$target' - something like: printenv bootcmd_usb I do not think the environment variable 'boot_armbian' exists on your board; I likely invented that myself, because I used to switch between the stock ubuntu and Armbian until I got Armbian working on my board. -But I think it's a good idea to check the environment variables that the Armbian booter likely would use... If they're all empty, it means that you'd have to enter them manually. If that's the case, I'd do something like... printenv console get_images set_bootargs load_script get_ramfs kernel_addr ramfs_addr fdt_addr That will print the values of those environment variables. If those environment variables are not empty, you might get away with very little typing, otherwise you may need to 'restore' the entire Armbian boot-setting by hand. Do this following step once only, it saves some of the old setup, in case you want to have a look at it later: setenv orig_bootcmd "$bootcmd" setenv orig_console "$console" saveenv Now, let's try and restore the boot to something that resembles Armbian's usual boot sequence. -Because I like being able to switch boot commands, I'll add an extra level in by adding the 'boot_armbian' variable. Remember that you can verify the values of your environment variables with the 'printenv' command after setenv... setenv console 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000' setenv root 'root=/dev/nfs rw' setenv ipaddr '0.0.0.0' setenv serverip '0.0.0.0' setenv gatewayip '10.4.50.254' setenv netmask '255.255.255.0' setenv hostname 'marvell' setenv netdev 'eth0' setenv rootpath 'rootpath=/srv/nfs/' setenv extra_params setenv bootcmd 'run boot_armbian' setenv boot_armbian 'run get_images; run set_bootargs; run load_script; booti $kernel_addr $ramfs_addr $fdt_addr' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $fdt_addr $fdt_name; run get_ramfs' setenv get_ramfs 'if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -; fi' setenv set_bootargs 'setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params' setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD"; setenv boot_interface mmc; else echo "... booting from USB"; usb start; setenv boot_interface usb; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' setenv kernel_addr '0x5000000' setenv fdt_addr '0x4f00000' setenv image_name 'boot/Image' setenv fdt_name 'dtb' setenv ramfs_name '-' saveenv -As written earlier, 'saveenv' will save your environment variables to SPI-Flash, so after typing 'saveenv' above, wait until you get the "Marvell>>" prompt back; do not do anything before you see the prompt. When you get back the prompt, make sure you have your micro-SD card inserted, then issue the following command: reset -If all goes well your board should start up. If not, I've likely made a typo somewhere, since I've typed all the above by hand, but I've checked each line more than 3 times, to make sure they're all correct - even so, there could still be errors.

-And I haven't even begun yet. I think it's important to understand the details on how the boot-process works. Once you have this knowledge, you'll know much better how to get things working if something gets messed up. The CPU has a small on-chip boot-ROM. In this boot-ROM, there's code that cannot be altered. This code is the code that checks the 3 jumper connections; usually these are set to load the boot-loader from SPI NOR-Flash. If there's something messed up, you'll not get the "Marvell >>" prompt, but instead you'll get a single "> " - still, don't worry if that happens, because there is a way out. When the boot-loader is 'trusted-firmware'-verified, then it is loaded (usually from SPI NOR-Flash as mentioned earlier, but could also be from SATA, UART or eMMC), and finally this boot-loader is executed. The boot-ROM code has now done its job. The bootloader that was just loaded and executed is usually Uboot (it could be anything; even your own code). This bootloader is the one that presents you with the "Marvell >>" prompt and allows you to interrupt the boot-process by pressing for instance space or return. If the bootloader is not interrupted by a keypress within the timeout (usually 2 seconds), then it issues one single command automatically: run bootcmd -This 'bootcmd' is nothing but an environment variable. It contains a string that is executed by Uboot's command-interpreter. You can issue this command to see what's in the variable: printenv bootcmd My 'bootcmd' looks like this: run boot_armbian -Yours might be different. So another environment variable is being executed by the command-interpreter. That environment variable holds instructions on ... 1: Get netboot images - just in case we're netbooting via PXE 2: Setup boot parameters 3: Probe the block devices, in order to find the most likely block-device to boot from (such as MicroSD-card/USB/SATA) Probing is usually done by the 'test' command. A boot-interface and boot-device is chosen (those are usually kept in environment variables) The boot-interface could for instance be "scsi" if you're booting from SATA or "mmc" if you're booting from a MicroSD card 4: Load the kernel image and emergency image (usually done by the ext4load command) 5: Execute kernel image (done by the 'iboot' command). When step 5 is executed, Uboot finished its task and the kernel takes over. If something goes wrong, the emergency disk image is brought up. ... If you at some point are at the "Marvell >>" prompt and want to play around, here's a few things you can try out: If you have a SATA disk connected: scsi scan; scsi dev 0:1 ext4ls scsi 0:1 / If you have a MicroSD card inserted: ext4ls mmc 0:1 / If you have a USB block-device attached: ext4ls usb 0:1 / ext4ls usb 1:1 / The number before the colon is the device number, the number after the colon is the partition. -So if you have your rootfs on partition 12 on your SATA drive, then you could for instance ... ext4ls scsi 0:14 /bin ... to see some of the executable files on that partition. Note: 'scsi scan' probes the SATA interface; you will not be able to do anything useful with the device without issuing that command. You can also set some environment variables if you wish to: setenv myVariable "echo hello there" printenv myVariable echo $myVariable run myVariable You should be able to execute the boot instructions one-by-one until you reach 'iboot'. Let's assume that you've found out how to make your board boot; you've written down all the commands necessary and tested that they indeed boot if you write them exactly as you have them ready (hopefully you have a terminal with copy-and-paste). When you've got your commands tested, you can set the environment variables and save those variables to your SPI-Flash using this command: saveenv Wait for the prompt to return. Make sure you can type on the command-line (thus you will know that the writing is done). After that, you can just boot as usual (either by typing 'boot' or 'reset' or by pressing the reset button). -Do *not* press the reset button while the flash-memory is being written to; that will surely mess up things. At this point, you may have tried some of the above; I expect that you're likely stuck somewhere, if so, please let me know where, so we can get you unstuck.

For anyone who wants to test power consumption, I'll recommend not supplying the board with 12V, but instead 5.2V, which is the minimum voltage required by the voltage regulator. The higher the input voltage, the higher power-loss you'll get. I recommend a good 5.2V PSU, which provides a heavy current like more than 3A. You can use a 6V PSU if you can't find anything lower, but just make sure that it can give the board a lot of current. For keeping power consumption down, I also recommend that you do not use the USB-ports nor the SATA port. That means booting Linux from the microSD card port - or if you want to cheat, you can supply an external harddisk with power from a different PSU and only connect the SATA data cable to the Espressobin. This will result in that the harddisk's power usage does not influence the measurements of the board itself. -And of course, as Thomas says - it's a very good idea shutting down peripherals you do not use. Unfortunately, there are things you can't change. The board has been sprayed with voltage regulators - even nested! I'm convinced that the board could have been designed a little better regarding this. I have not checked if you can shut down some of the power regulators completely, but even if you issue the "poweroff" command, the CPU is still running!! Things to consider: Powering a SATA drive from the board uses a lot of power. A 3.5" drive use much more than a 2.5" drive (check your drive's specs). USB devices use lots of power. MicroSD / MMC uses some power, but it's not extreme. A Mini-PCIe WiFi card uses a lot of power; I'm fairly convinced that the built-in Gbit Ethernet uses less. (unfortunately the Topaz switch has not been utilized very well on the board; it's fairly much a waste, it's just using power without giving extra performance). The DDR RAM uses a fair amount of power, but for good reasons it's not smart to turn it off. ... All those things add on top of the CPU's own power usage, which is said to be 1W. At the moment, I do not have the proper equipment ready for measuring the power usage on the board; but if I find a way, I'll be using a multimeter and a 5.2V power source - and I'll likely be running Armbian from the SD-card or perhaps cheating by running it from a SATA disk with a secondary power supply, so you can easily add your own numbers for the harddisks of your choice.

Thomas, did you get your board up and running again ? -If not, don't worry, it's not as bad as it may seem. I'll be happy to help you get it up and running. Here's a simple overview of what happens during boot: There are two stages: 1: The "Marvell >>" prompt is actually Uboot, the boot-loader. If you haven't updated your boot-loader yet, you can do so from within Uboot, but you need to write the image to either a microSD card or a USB-stick first. When you've updated your boot-loader with the correct version, you can update the boot instructions. (The boot-instructions are actually stored in environment variables). You can experiment with the environment variables manually at no risk of wearing out the flash-memory. If you reboot, those experiments will have to be re-typed, as they're not saved in the SPI-flash. When you're satisfied with your experiments, you can save the environment variables. Normally, Armbian is written to the SD-card's first partition; this partition acts both as the boot partition and as the root file system. (Some linux distributions have boot and rootfs on different partitions). ... I'll be happy to write in further details where needed, but it would likely be too much writing the entire boot process in a single post.

Today I tried to install the latest bionic image; the Armbian_5.59_Espressobin_Ubuntu_bionic_next_4.18.6. The first thing I tried was making a tarball, then writing this tarball to a freshly formatted partition and modifying it. This almost booted with a few tweaks; I was dropped into an emergency shell. I managed to get it running, however, there is no network connection at all; the LED on the network interface stays off. (I did expect that would happen at some point, since that happened with earlier versions after 'apt upgrade'). Not being able to figure out what caused the emergency shell to be invoked, I thought that I'd try installing the tarball on a freshly formatted partition without modifying anything after the installation. That resulted in a never-ending loop of requesting root to change password from 1234 to something else. So I finally gave in and wrote the image to a brand new Sandisk microSD card. I attempted to boot that from USB, but since that didn't work, I moved the card to my microSD card slot. That didn't go well either. I actually forgot what the problem was by now, but it didn't get very far. ... Has the Armbian_5.59_Espressobin_Ubuntu_bionic_next_4.18.6 image been tested on an Espressobin board ? -Did anyone succeed in booting from it yet ? -Anyone got network connection on the board with this new image ?

Found it. You'll need a USB-to-UART adapter, there are plenty of different models on eBay. I very much like CP2102 because there are drivers even for my PowerPC based Macs. -Remember to connect only GND, RxD and TxD. Do not connect VCC. Here's a direct link to the UART debug console page. It also explains the details of the RxD/TxD cross-wiring.

This sounds like that the system on your microSD card is damaged in some way. I have a Cubieboard2 as well and I had to borrow the SD-card for my Espressobin, so I made a backup of the card, then wrote the Espressobin booter, booted the Espressobin and made some installations. When I restored my SD card contents, the Cubieboard2 did not boot from it. Attaching a TFT monitor did not help me either. Here I know for certain that I changed my microSD card is the cause. I very much recommend that you try writing the system to a fresh, unused microSD card (then the chance of getting data-corruption due to wear-out is very small). Note: If your Cubieboard2 was writing logs to your microSD card, this could very likely be a reason that the card is worn out. These days, you should be able to get a real good 90MB/sec 16GB card for $6 (or 5.5 Euro).

I've gotten a little further with finding out what makes "apt upgrade" stop working on the Espressobin (this likely applies to both Bionic and Xenial). As soon as I boot Bionic, I see that 2 upgrades are available, before I issue 'apt update'. I can safely issue 'apt upgrade' without first issuing 'apt update'! After rebooting, network is still online. If I then do an 'apt update' followed by 'apt upgrade apt' (eg. only the first upgradable item in the list), I lose network when setting up systemd ... -So far, so good; I'll try and see how many packages can be upgraded without losing network; so for now I'll try avoiding upgrading systemd. I've also noticed that both 'poweroff' and 'reboot' hangs here ... I've begun using these instead of 'reboot' and 'poweroff'; I have not experienced that they hang yet: sudo systemctl poweroff sudo systemctl reboot I'm successfully running the following on both Bionic and Xenial: Redis (3 instances) Git+gitolite+gitweb (11 different locations, 11 x gitweb too) with login on port 9418 NFS Netatalk-3.1.11 Nginx-1.14.0 with the horrible fcgicrap GeoIPLite2 with CPAN modules Transmission (for Armbian torrents) Archivemount, unar, unzip Unbound Disabled RAM logging (since I run on SATA) Disabled unattended upgrades (since I'm running the boards as servers) BTRFS on all partitions except from the boot and root partitions 200+ web sites with CGI-scripts (ported from Apache in less than a week) - much more responsive than Apache2 on my Mac Mini Note: If running Redis-server 4.0.11, the CPAN module will not build, due to that some strings have been changed in Redis. The easy fix is to install redis-server-4.0.10 and then install the CPAN module. This also means that you should not upgrade Redis after that. On Xenial, I was able to build and run my own version of cfgiwrap, but on Bionic, I've made several attempts and can not get it to work - even if I manually just replace the binary and nothing else. I've tried downloading different versions of fcgiwrap (even from Ubuntu/Bionic), but no dice so far. It's likely I'll be building and installing qmail next - I had to upgrade the TLS code, since Bionic comes with OpenSSL-1.1.0, which means the currently available code and patches fail.

OK, I'll probably make a simple systemd service that logs disk-space or something and send me an email if a high-watermark is reached. :)

For anyone coming across this: Removing the symlink didn't work for me on Espressobin, but the following did: systemctl stop serial-getty@ttyS0.service

Thank you, sir! :) I've cleaned my drive, so I now have a clean download of the files. I'll check now and then if files get deleted or if the usage grows, because I sense something might have gone wrong with file-deletion. While I remember ... I've set up transmission to have a 'completion directory' which is different from the 'in-progress' directory. Would this cause any problems ?

when I do ... sudo ip addr 10.0.2.80/8 dev wan ... I still have the LED light on the WAN connector, and I can confirm the address is set with 'ip a', but I cannot SSH into that address (like I usually can if the address is assigned without upgrading or by a DHCP server). I tried making a diff -ur between the un-upgraded system and the upgraded system. The only difference is in /lib/systemd/system/unattended-upgrades.service: -ConditionACPower=true In other words: the configuration files seem to be unchanged, so that configuration files that previously worked don't work any longer (unless there are more configurationfiles elsewhere) I also noticed that some binaries (including /lib/systemd/system/systemd-{networkd,resolved}) had changed, so I decided to try and smash things alittle by replacing them one-by-one (resulting in a franken-linux) - but that didn't make any difference - worth the try, though. Note: This does not prove that those binaries aren't at fault. More info: Normally, before upgrading, I can SSH into the Espressobin before the login-prompt comes up in the terminal. But when I have the modification in rc.local, I will need to wait trying until the login-prompt appears (and the LED light comes on on the WAN port). That means the difference (eg. the change) is somewhere much earlier; the problem could be in one of the binaries of course.

I now made the above modifications; eg. adding only one line to /lib/systemd/system/systemd-networkd.service and also adding the suggested line for rc.local right before 'exit 0'. This definitely makes a differnce. When I reach the login-prompt in the (serial) terminal, the network-light comes on on the WAN 8P8C connector. -But neither Lampra's nor my own /etc/systemd/network/10-* settings assigns an IP address to the WAN interface. If I do an ifconfig -a | grep inet, I do not see any ip-addresses belonging to my LAN (which is where the 'WAN' port is connected). @Smurfix: I (strongly) acknowledge that I should not edit stuff in /lib and once a solution is found, I'll use /etc for the final setup - but while I'm testing anyway, I might as well just mess up the system, since I'll do a complete re-install anyway when things do not work - I cannot use any editor from the serial terminal, thus I'd prefer having nano via SSH; this kinda requires me to re-install.

I think you're right. If we take 1200*1000*1000/1/2/4/6, we get 25000000 (25 MHz), which I assume is the base frequency. 25 MHz*1*2*3*4 = 600 MHz, so the 600MHz entry is actually alright. It's the 800MHz entry, which looks wrong to me. I don't know what the restrictions are, but 25MHz*1*2*4*4=800MHz. 750MHz could probably be {1,2,3,5} 900MHz could probably be {1,2,3,6} I don't know if any of those would work, though.

Alright- 378 ... That means I have 10 files more than I should have. I'll add an additional drive, the next time I get over to my server; it's more important that you spend time making more images available than keeping the number of files down; worst case would be that I transfer the files to my local Espressobin and let it handle it until I get more space. Perhaps I'll need to make a split disk-image in order to solve the problem that the partition will soon be full. (By making a split disk-image, I mean spreading disk images over several partition and setting them up in RAID0; this works fine and can be mounted in fstab too. It's also possible to mix images with real partitions).

I've been seeding torrents on my CubieBoard2 earlier; in Juli I moved to one of my EspressoBIN boards. I allocated 128GB for the torrents (since it was stated that I needed at least 60GB for Armbian). -But now Armbian seem to take up 123GB on my dedicated transmission partition: $ df -h . Filesystem Size Used Avail Use% Mounted on /dev/sdc13 128G 123G 4.5G 97% /transmission It seems I have 388 completed Armbian files (and no other files). -Does this mean that something went out of control - like files not being deleted - or does it mean that the torrents use this much space now ?

Thank you again, Lampra. This worked for me. Here's what I did: sudo apt install unbound sudo systemctl disable systemd-resolved.service sudo service systemd-resolved stop sudo nano /etc/systemd/network/10-br0.network #---8<-----8<-----8<-- [Match] Name=br0 [Network] Address=10.0.1.2/8 Gateway=10.0.0.1 #--->8----->8----->8-- sudo reboot (now I got a static IP)

This is how I've currently set up my u-boot: setenv bootcmd 'run boot_armbian' setenv boot_armbian 'run get_images; run set_bootargs; run load_script2; booti $kernel_addr $ramfs_addr $fdt_addr' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $ftd_addr $ftd_name; run get_ramfs' setenv get_ramfs 'if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -; fi' setenv set_bootargs 'setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params' setenv load_script2 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else echo "booting from SATA"; scsi scan; setenv boot_interface scsi; scsi dev 0:1; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' # A suggested, but untested SATA-boot (try MMC first, then USB, then SATA): setenv load_script3 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else usb start; if test -e usb 0:1 boot/boot.scr; then echo "... booting from USB"; setenv boot_interface usb; else echo "booting from SATA"; setenv boot_interface scsi; scsi scan; scsi dev 0:1; fi; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' There might be typos, because I don't have any copy-and-paste from my serial terminal and in addition, load_script3 has not been tested, so it may contain errors as well. -But you should get the idea; it's in fact just a tiny addition to armbian's default setup.

Thank you for the suggestion; I'm sorry it took me so long to post a reply; my Mac lost both network ports, but now I got myself a working PCIe card for it from IOCrest. I tried the above (on a clean bionic install without any updating), then rebooting and it seems I lost the network. I also tried clean install, apt update; apt upgrade then applying the above modification, but network never came up after that.

I've set up my local EspressoBIN with 18.04 Bionic (Armbian_5.44_Espressobin_Ubuntu_bionic_next_4.14.40.7z). My impression is that it's very much like setting up Xenial and the same issues seem to be present. I mention them in the order of importance. 1: #reboot sometimes hang, so does #poweroff. It would be great to get this fixed, because it would be a disaster if a device hangs on rebooting from remote (eg. the device is 200km away). 2: sudo apt-get update && sudo apt-get upgrade destroys the network setup. No network access is possible after doing this. I think a fix is important, because people would likely issue those commands. 3: Network seem to be configured slightly different than on Xenial; it seems I cannot configure a static IP on the WAN port (see my other post specifically on static IP). For now, I'll be using a static IP address on the br0, this works, so it's not the highest priority. I definitely also need to write some good stuff. 1: 3Gbit JMB321 Port Multipliers work well with Xenial (and likely also Bionic); just remember to connect the boot device to SATA0 and there should be no problems. 2: 6Gbit JMB575 (StarTech) works great with Bionic (and likely also Xenial); again connect the boot device to SATA0. For those, who want to boot "directly" from SATA, this is what I do on both boards; it's fairly easy and there are plenty of ways you can do it. The first time, I just made a 'dd' from my SD-card's partition to my harddisk's partition. This works fine and the partition will be expanded when Armbian boots. My preferred way, though, is to make a tarball of the unmodified SD-image's partition, boot my EspressoBIN from the SD-card and extract the files onto my desired partition. This gives me a different UUID from the SD-card, thus inserting the Armbian SD card won't confuse my boot-up sequence. To create a tarball, this can be used (mounted as /mnt/sd) ... cd /mnt/sd && sudo tar -cpzf /data/armbian-bionic-rootfs.tar.gz . To extract onto your partition (mounted as /mnt/rootfs), this can be used ... cd /mnt/rootfs && sudo tar -xpzf /data/armbian-bionic-rootfs.tar.gz -C . Those will preserve permissions, timestamps and other attributes as necessary, but this will only happen if you're root, otherwise permissions will be messed up and you'll get a half-working system (quite useless). I use a custom UUID on my own setup, so that I only need to set it once in u-boot. I highly recommend using UUID for identifying the boot device, especially is you use a port multiplier, because you never know if a USB-drive suddenly get /dev/sda instead of the drive you expect. In your startup boot sequence, I recommend a 3-stage check ... 1: Check for SD-card (SD/MMC slot) 2: Check for USB-boot 3: Use a 'scsi scan; scsi dev $bootdev:$bootpart;' then check for your SATA-device here. Personally I only have step 1 and 3, since I often mount my SD-card as a USB-drive when I do not want to boot from it.