Igor

It should be the same ... you need to manually adjust this parameter until we rebuild the images. This will happen once this week ... still fixing some other things. I assume you can boot your 1Gb board when applying a fix?

Try this: https://github.com/armbian/build/commit/475f0cbd8700db23d882faca891f9c7196e824c0 Edit /boot/armbianEnv.txt on some other machine, where you can mount this SD card.

1Mb version?

Python is installed by default ... while Python I/O libraries are not.

Perhaps CMA reservations have something to do with this. We would like to provide this for older kernels as well. Lowest is 3.4.y and I made several tests without a problem. The only problem was detected on Bionic, where ZRAM is failing sometimes. Also with a stock script. Haven't got chance for deep analysis ... Bionic bugs are not exactly a top priority ATM.

Imagine how this sucked before we start this project. No, we don't deal with ZFS but it's again something that can be added if someone put some time into this. We have plenty of other fundamental problems and features as such rarely come high on priority list.

Restored.

Support is not on the x86 level yet in areas such as DKMS. It works on some kernels, but mostly it's broken. You still can compile drivers, since headers are available by default, but auto updating will not work. Each family has it own kernel, maintaining is scattered around, mainlining is still months to years behind, some kernels are critically old. 8812AU (also 8811AU and 8814AU) NIC is supported by Armbian out of the box, drivers are built into the kernel (except those critically old ones) and we update them, so you don't need to compile anything. With best possible driver.

Is this still present? This looks like a temporally (upstream) network related bug. Yes. Fixed. Now it is also clear why u-boot was from Rock64 ... I haven't notice error while compiling ... and since u-boot was already present (not cleaned properly) ... it didn't break the compilation. I'll remake it and put to the server.

https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-kernel-config

Well, I didn't test it and I can only wait that someone builds it and confirm. Then I'll do it again.

Nope. It was Renegade. I rebuild for Rock64 this afternoon after this and it works/boots fine. (it was broken too)

https://github.com/armbian/build/commit/8aacc920dac3f23e28d7dcc6cc666eb2c73db48f One down. Thanks.

There is no support for WIP so your questions will be/are ignored anyway. And you have no right to create any pressure on developers. (not the first time)

https://github.com/armbian/build/commit/c63b2129f64a741d71b30bc7bf3bb6ede98de6fb I attach to last known for now. It's better than having a broken system. I did test and boot Rock64 ... check Renegade and I'll remake the images if it works as well.

Perhaps related to this: It was already fixed, so you need to adjust fix or recreate image.

Go to /etc/defaults/armbian-zram and armbian-ram-log ... and customize/disable. I couldn't boot the image with *3 Ubuntu Xenial / 3.4.113, made 30 minutes ago from sources ... without everything works/looks normal.

You were right, ZRAM changes had effects. Fixed: https://github.com/armbian/build/commit/908dd71d2d8934666dd6ee3502ccf07a693b27ab Thanks! @Arglebargle

Github was acquired by criminals and our code is ... gone bad? My first try ended up: Perhaps your SD card simply died? I have a stack of broken Samsung EVO around ...

Got it. Well, then we are more talking about a backup / restore situation here. I tend to only backup the data and not the operating system. That is easy to install from scratch and when you do this, you can jump to the latest version ... A way to do this is to make install scripts. A direct consequence of having an easy to reinstall everything is this: https://github.com/armbian/config/blob/master/debian-software I made it initially to set up a (fairly complicated) LAMP setup for my personal needs. I also made a simple script to dump and import SQL data and tar/untar data directories and save configs that were custom and that's about it. I know it is a little more work for a start, but a backup is populated with as less junk as possible and I could easily migrate it to different systems and hardware platforms. And I acttually did it several times, jumping between ARM and X86, Wheezy to Stretch.

Well, that is a kernel label ... which is (kind of) stable. Huh. Board is labeled as "no official support" ... I see that we will need to rework this logic a bit. ... and since I don't own this board, I have no idea if its working.

@JMCC Done. https://www.armbian.com/renegade/

Shell we change roc-rk3328-cc to renegade-rk3328 (or just renegade?) before making a test build?

We made new images a few days ago. Try these: https://www.armbian.com/lepotato/ (v5.49 Debian Stretch Default with 4.14.52)

It should. Armbian can be "manufactured" and it's with a separate, FAT or ext4, boot partition on OMV. Rootfs can be ext4 or btrfs. https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-resize-filesystem