Igor

Wait that we fix repository which was (not correctly) updated yesterday or manual way.

This means we have some trouble with the repository. You don't need to do anything. It will be fixed asap / eventually.

Then it should work. In a theory ... I have no other ideas ATM

Those settings are not related to u-boot.

If it's Stretch related, then we are too fast with it even for a server builds. Somebody has to take the lead and I left this task to @Tido and things are not running smoothly yet. Also because of breaking releases into two parts. We did quick testing on critical stuff and the team testing part was left for 4.14.y update. This was kind of compromise and give some time to prepare: the vital job description of "team tester leader" is to ping people from time to time, otherwise, they just don't react on "you have been assigned to the task of testing this and that. My emails are up to 3 weeks behind and I can't possibly cover more one2one communication. Eiter we help @Tido to get this up and running or come up with a better plan.

If you have internet access please provide the output of: armbianmonitor -u Also good to know: uname -a

I can't confirm or deny if we have some problems since we changed few things and I haven't really made an image in the last 24h.

I was thinking the other day to RFC main readme. Move all to documentation and leave only reduced text: Build system req: Ubuntu 16.04.y X64 (native, containerized, virtualized) + "detailed specifications and advanced build options" with a link to docs + why only Ubuntu?

Are you booting legacy 3.4.y kernel? Then lack of script.bin is a problem.

At least that is correct Only BSP package was updated and at least most non-cosmetic problems were fixed ... Well, we need yet another mini updated. There are only experimental 4.13.y builds and yes its planned when ready and tested. That is completely normal. SD card content is left as is. We only alter boot environment when SD card is needed for booting. We only fixed bugs inboard support package scripts. There were no kernel updates and this problem need to be investigated. It's nothing critical so you can normally use the board.

done. apt-update & upgrade

Those number might be set higher later when the kernel is well tested and thermal protection working as it should. You don't want to burn your board, do you?

Since the nightly building is still on hold, you need to make one. I'll try to make one later if you can't build it.

Yes, there is a strong reason called "waste of scarce human resources" to gain little on a less important area. There are only a few people working on/supporting/developing a build engine ... which anyway support building withing Docker. This means you can actually build anywhere - at any x64 Linux Docker capable host. In case this bothers you a lot and you want to dedicate your time to this challenge: https://docs.armbian.com/Process_Contribute/

No need to format anything. Check is crucial that's why we suggest Etcher and if you can, try some other SD card. I am not sure exactly for image which you are trying, but this one: https://dl.armbian.com/tinkerboard/nightly/Armbian_5.35.171130_Tinkerboard_Ubuntu_xenial_next_4.14.2_desktop.7z was tested personally and it works this way: 4.14.y is recommended since we are ditching 4.13.y ASAP.

https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

v.5.36 Are we ready to rebuild repository on Sunday ... and update only BSPs and RPI monitor?

Just check project Github if there was any progress on this. In case of major progress, we mention that in a release log. It can take months, sometimes a year(s) before board is labeled stable. I only have RK3328 based TV box and have to get Rock64 first I'll check what can be done but in any case, this will still be a testing build.

Unfortunately, you hit another (known) Ubuntu Xenial bug. Only Debian Stretch desktop is currently available to build for imx6 based boards. I didn't have time to get to the bottom of the issue so I don't know exactly where is the problem and how to solve it.

Those are logs from image: http://sprunge.us/WUDf where HDMI audio was tested successfully. Board is Opi PC+

Remember. This is open source project running by amateurs and not enterprise-grade service. Go to GitHub and monitor progress. We always write major changes to release documentation. Didn't you notice this? * packaged versions might be slightly older than in this table!

Add this extraargs=net.ifnames=0 to /boot/armbianEnv.txt

I didn't get this far yet. I have system on eMMC now, can boot from it and (only) waiting in the corner Busy with other stuff.

Since image currently doesn't boot properly, somebody needs to find and fix this problem first.

NAND is fading out and probably CHIP is one of the last if not the last one using this technology. It's one of those - yes I would like to see this - but it is a low priority from our perspective. I notice that @zador.blood.stained add overlays for NAND and we have support at least in a modern kernel (I only saw NAND was recognized, but haven't actually tested its functionality), while old legacy is officially EOL and we will ditch it once multimedia functions/video acceleration/MALI works in mainline.