Jump to content

Search the Community

Showing results for 'f2fs'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Advanced users - Development
  • Upcoming Hardware (WIP)
    • News
    • Odroid M1
    • ROCK Pi 5B
  • Maintained Hardware
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Unmaintained (CSC/EOL/TVB) / Other
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP


Skype


Github


Discord


Location


Interests

  1. Description Issue #4031 supports label. But the flag for label in mkfs.vfat and mkfs.f2fs isn't -L. How Has This Been Tested? [X] Build Checklist: [ ] My code follows the style guidelines of this project [X] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article
  2. Well, usually f2fs is the generally recommended filesystem for flash-based devices, but it's a matter of personal opinion, since many people say they get good results with btrfs or even ext4...
  3. Since I've been asked recently why Armbian doesn't ship with F2FS by default I thought let's have a look again what to gain from F2FS (a filesystem specially designed for use with flash media by Samsung few years ago). For a history of F2FS discussion please use the search function: https://forum.armbian.com/index.php?/search/&q=f2fs Armbian fully supports F2FS partitions for a long time now but we don't provide OS images with F2FS for a couple of reasons: F2FS still doesn't support resizing so our default installation variant (ship with a minimized rootfs that gets resized on first boot automagically to the size of SD card / eMMC) wouldn't work F2FS requires a pretty recent kernel and is therefore not an option for default images (since most of downloads use legacy kernel) Unfortunately those installations that would benefit the most from faster random IO (writes) are those using the kernels most outdated (Allwinner A20/H3 who are used by many people as 'desktop linux' where performance heavily depends on fast random writes) To use F2FS with Armbian you need to choose a SoC family that is supported by mainline kernel (or at least 4.4 LTS) and then build an image yourself using these options (choosing $FIXED_IMAGE_SIZE to be less than the capacity of the final installation media!) ROOTFS_TYPE=f2fs FIXED_IMAGE_SIZE=n In the past I tested through this many times and all my tests didn't show that great performance improvements would justify another installation variant but... let's have a look again and focus on the claims first. F2FS has been invented to solve certain problems with flash based media and promises better performance and higher longevity. At least measuring the latter is somewhat questionable but performance can be tested. So I decided to pick 3 different SD cards that represent roughly the kind of flash media people out there use: Crap: An Intenso 4GB Class 4 SD card Average: A random SanDisk 8GB card Superiour: An expensive SanDisk Extreme Plus with 16GB For the tests I used an OrangePi One with kernel 4.10 and a Debian Jessie variant to be able to use a scripted OpenMediaVault installation as some sort of a real-world benchmark (the script is roughly based on the results of our OMV PoC). The other 3 benchmarks are our usual iozone3 call, then ioping and a mixed workload measured with fio. Test script is this: https://pastebin.com/pdex14L9 First results with an average SanDisk 8 GB card (debug output with F2FS and with EXT4): F2FS EXT4 iozone 4K random write IOPS 208 196 iozone 4K random read IOPS 1806 1842 iozone 1MB sequential write KB/s 7161 10318 iozone 1MB sequential read KB/s 22429 22476 ioping k iops 1.42 1.31 fio write iops 128 132 fio read iops 384 395 OMV installation time in sec 886 943 I consider benchmark numbers that vary by less than 10% as identical and then it's easy: ext4 outperforms F2FS since all results are identical but sequential reads are +40% faster with ext4. Test results in detail: F2FS and EXT4. I'm really not impressed by any differences -- only two things are interesting: faster sequential reads with ext4 but very low random IO write performance at 16K blocksize (that's something we noticed with a lot of SD cards already, see first post in 'SD card performance' thread). At the moment I'm not that impressed by performance gains (but that might change later when the crappy 4GB card has finished) and just want to point out that there are other criteria too for choosing a filesystem for systems that are running with a high potential for bit flips (due to users using crappy chargers, bad DRAM clock settings when not using Armbian and so on). Just to give an idea please read through the PDF link here: https://news.ycombinator.com/item?id=11469535 (ext4 more than 1,000 times more reliable than F2FS when running the AFL test against) BTW: mkfs.f2fs info at image creation time (no idea whether something could be 'tuned' here): Info: Debug level = 0 Info: Label = Info: Segments per section = 1 Info: Sections per zone = 1 Info: Trim is enabled Info: sector size = 512 Info: total sectors = 7649280 (3735 MB) Info: zone aligned segment0 blkaddr: 512 Info: format version with "Linux version 4.4.0-72-generic (buildd@lcy01-17) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017" Info: Discarding device Info: Discarded 7649280 sectors Info: Overprovision ratio = 3.300% Info: Overprovision segments = 126 (GC reserved = 68) Info: format successful
  4. Hello, i've preordered an Helios64 and would like to install the main os on a f2fs formatted sd-card. your documentation says that this is not possible, and i would love to see this possibility. i guess most eMMC devices would also benefit
  5. My Rock Pi S logs a NULL pointer dereference in the ext4 module after running for 1 to 3 hours. Subsequently existing processes continue to run but it appears that new processes can't start (eg I can't ssh in). The filesystem is on a new Sandisk Ultra Plus microSD card. As a test, I remounted the root filesystem read/write and the board ran flawlessly for 10 hours. When I get time I will try rebuilding the image with the root filesystem on F2FS. Aug 31 09:31:27 rockpi-s kernel: [ 1944.993824] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Aug 31 09:31:27 rockpi-s kernel: [ 1944.994681] Mem abort info: Aug 31 09:31:27 rockpi-s kernel: [ 1944.994952] ESR = 0x96000004 Aug 31 09:31:27 rockpi-s kernel: [ 1944.995248] EC = 0x25: DABT (current EL), IL = 32 bits Aug 31 09:31:27 rockpi-s kernel: [ 1944.995732] SET = 0, FnV = 0 Aug 31 09:31:27 rockpi-s kernel: [ 1944.996020] EA = 0, S1PTW = 0 Aug 31 09:31:27 rockpi-s kernel: [ 1944.996313] Data abort info: Aug 31 09:31:27 rockpi-s kernel: [ 1944.996587] ISV = 0, ISS = 0x00000004 Aug 31 09:31:27 rockpi-s kernel: [ 1944.996943] CM = 0, WnR = 0 Aug 31 09:31:27 rockpi-s kernel: [ 1944.997230] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003851000 Aug 31 09:31:27 rockpi-s kernel: [ 1944.997813] [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000 Aug 31 09:31:27 rockpi-s kernel: [ 1944.998587] Internal error: Oops: 96000004 [#1] PREEMPT SMP Aug 31 09:31:27 rockpi-s kernel: [ 1944.999104] Modules linked in: rfkill snd_soc_rk3308 snd_soc_core snd_pcm_dmaengine snd_pcm cdc_acm snd_timer snd soundcore cpufreq_dt zr am ip_tables x_tables autofs4 realtek dwmac_rk stmmac_platform stmmac pcs_xpcs Aug 31 09:31:27 rockpi-s kernel: [ 1945.001035] CPU: 3 PID: 213 Comm: kworker/u8:3 Not tainted 5.10.60-rockchip64 #21.08.1 Aug 31 09:31:27 rockpi-s kernel: [ 1945.001746] Hardware name: Radxa ROCK Pi S (DT) Aug 31 09:31:27 rockpi-s kernel: [ 1945.002197] Workqueue: writeback wb_workfn (flush-179:0) Aug 31 09:31:27 rockpi-s kernel: [ 1945.003074] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) Aug 31 09:31:27 rockpi-s kernel: [ 1945.004117] pc : clear_page_dirty_for_io+0x38/0x278 Aug 31 09:31:27 rockpi-s kernel: [ 1945.005032] lr : clear_page_dirty_for_io+0x18/0x278 Aug 31 09:31:27 rockpi-s kernel: [ 1945.005936] sp : ffff8000123db730 Aug 31 09:31:27 rockpi-s kernel: [ 1945.006875] x29: ffff8000123db730 x28: ffff8000123db9a0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.007607] x27: 00000000000021f9 x26: 0000000000000001 Aug 31 09:31:27 rockpi-s kernel: [ 1945.009006] x25: 000000000008c1f9 x24: 000000000000000c Aug 31 09:31:27 rockpi-s kernel: [ 1945.009951] x23: fffffe00003c7340 x22: ffff0000066b5400 Aug 31 09:31:27 rockpi-s kernel: [ 1945.010761] x21: ffff8000123db870 x20: fffffe00003c7340 Aug 31 09:31:27 rockpi-s kernel: [ 1945.012020] x19: fffffe00003c7340 x18: 0000000000000000 Aug 31 09:31:27 rockpi-s kernel: [ 1945.012965] x17: 0000000000000000 x16: ffff000002259110 Aug 31 09:31:27 rockpi-s kernel: [ 1945.014196] x15: 0000000000000001 x14: 0000000000000002 Aug 31 09:31:27 rockpi-s kernel: [ 1945.014706] x13: 0000000000005966 x12: 000000000000000b Aug 31 09:31:27 rockpi-s kernel: [ 1945.015216] x11: 0000000000000000 x10: ffff000006804540 Aug 31 09:31:27 rockpi-s kernel: [ 1945.015724] x9 : 0000000000000001 x8 : 0000000000000000 Aug 31 09:31:27 rockpi-s kernel: [ 1945.016230] x7 : 00000000001f9000 x6 : fffffe00003c7300 Aug 31 09:31:27 rockpi-s kernel: [ 1945.016751] x5 : 00000000171cc000 x4 : 0000000000000000 Aug 31 09:31:27 rockpi-s kernel: [ 1945.017258] x3 : 00000000000021f8 x2 : ffff0000004df800 Aug 31 09:31:27 rockpi-s kernel: [ 1945.017779] x1 : 0000000000000000 x0 : ffff0000036799d8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.018291] Call trace: Aug 31 09:31:27 rockpi-s kernel: [ 1945.018544] clear_page_dirty_for_io+0x38/0x278 Aug 31 09:31:27 rockpi-s kernel: [ 1945.018998] mpage_submit_page+0x30/0xa0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.019379] mpage_map_and_submit_buffers+0x168/0x2a8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.019856] ext4_writepages+0x748/0xc38 Aug 31 09:31:27 rockpi-s kernel: [ 1945.020236] do_writepages+0x58/0x100 Aug 31 09:31:27 rockpi-s kernel: [ 1945.020598] __writeback_single_inode+0x44/0x508 Aug 31 09:31:27 rockpi-s kernel: [ 1945.021037] writeback_sb_inodes+0x1e0/0x478 Aug 31 09:31:27 rockpi-s kernel: [ 1945.021460] __writeback_inodes_wb+0x78/0xe8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.021865] wb_writeback+0x26c/0x400 Aug 31 09:31:27 rockpi-s kernel: [ 1945.022218] wb_workfn+0x310/0x5f8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.022549] process_one_work+0x1ec/0x4d0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.022935] worker_thread+0x48/0x478 Aug 31 09:31:27 rockpi-s kernel: [ 1945.023287] kthread+0x140/0x150 Aug 31 09:31:27 rockpi-s kernel: [ 1945.023605] ret_from_fork+0x10/0x34 Aug 31 09:31:27 rockpi-s kernel: [ 1945.023962] Code: b000b402 f9401401 f9474042 eb02003f (54000de0) Aug 31 09:31:27 rockpi-s kernel: [ 1945.024526] ---[ end trace cdc066846165d221 ]--- Aug 31 09:31:27 rockpi-s kernel: [ 1945.025183] ------------[ cut here ]------------ Aug 31 09:31:27 rockpi-s kernel: [ 1945.025659] WARNING: CPU: 3 PID: 213 at kernel/exit.c:725 do_exit+0x44/0xab8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.026307] Modules linked in: rfkill snd_soc_rk3308 snd_soc_core snd_pcm_dmaengine snd_pcm cdc_acm snd_timer snd soundcore cpufreq_dt zram ip_tables x_tables autofs4 realtek dwmac_rk stmmac_platform stmmac pcs_xpcs Aug 31 09:31:27 rockpi-s kernel: [ 1945.028231] CPU: 3 PID: 213 Comm: kworker/u8:3 Tainted: G D 5.10.60-rockchip64 #21.08.1 Aug 31 09:31:27 rockpi-s kernel: [ 1945.029079] Hardware name: Radxa ROCK Pi S (DT) Aug 31 09:31:27 rockpi-s kernel: [ 1945.029525] Workqueue: writeback wb_workfn (flush-179:0) Aug 31 09:31:27 rockpi-s kernel: [ 1945.030047] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) Aug 31 09:31:27 rockpi-s kernel: [ 1945.030612] pc : do_exit+0x44/0xab8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.030956] lr : die+0x208/0x248 Aug 31 09:31:27 rockpi-s kernel: [ 1945.031260] sp : ffff8000123db380 Aug 31 09:31:27 rockpi-s kernel: [ 1945.031576] x29: ffff8000123db380 x28: ffff0000029fe580 Aug 31 09:31:27 rockpi-s kernel: [ 1945.032086] x27: 00000000000021f9 x26: 0000000000000001 Aug 31 09:31:27 rockpi-s kernel: [ 1945.032594] x25: ffff80001023b328 x24: 0000000000000000 Aug 31 09:31:27 rockpi-s kernel: [ 1945.033100] x23: ffff8000123db497 x22: ffff800011270260 Aug 31 09:31:27 rockpi-s kernel: [ 1945.033605] x21: 000000000000000b x20: ffff8000118b9948 Aug 31 09:31:27 rockpi-s kernel: [ 1945.034112] x19: ffff0000029fe580 x18: 0000000000000010 Aug 31 09:31:27 rockpi-s kernel: [ 1945.034617] x17: 0000000000000000 x16: ffff000002259110 Aug 31 09:31:27 rockpi-s kernel: [ 1945.035128] x15: 00000000000001b7 x14: ffff8000123db0c0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.035643] x13: 00000000ffffffea x12: ffff80001194ee98 Aug 31 09:31:27 rockpi-s kernel: [ 1945.036152] x11: 0000000000000003 x10: ffff800011936e58 Aug 31 09:31:27 rockpi-s kernel: [ 1945.036660] x9 : ffff800011936eb0 x8 : 0000000000017fe8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.037167] x7 : c0000000ffffefff x6 : 0000000000000001 Aug 31 09:31:27 rockpi-s kernel: [ 1945.037689] x5 : 0000000000000001 x4 : 0000000000000000 Aug 31 09:31:27 rockpi-s kernel: [ 1945.038200] x3 : 0000000000000000 x2 : ffff8000118b9948 Aug 31 09:31:27 rockpi-s kernel: [ 1945.038707] x1 : ffff8000123dbc90 x0 : ffff00001d6b8c88 Aug 31 09:31:27 rockpi-s kernel: [ 1945.039216] Call trace: Aug 31 09:31:27 rockpi-s kernel: [ 1945.039471] do_exit+0x44/0xab8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.039783] die+0x208/0x248 Aug 31 09:31:27 rockpi-s kernel: [ 1945.040070] die_kernel_fault+0x64/0x78 Aug 31 09:31:27 rockpi-s kernel: [ 1945.040441] __do_kernel_fault+0x74/0x148 Aug 31 09:31:27 rockpi-s kernel: [ 1945.040826] do_page_fault+0x1c8/0x3a8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.041206] do_translation_fault+0x50/0x60 Aug 31 09:31:27 rockpi-s kernel: [ 1945.041605] do_mem_abort+0x40/0xa0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.041944] el1_abort+0x48/0x70 Aug 31 09:31:27 rockpi-s kernel: [ 1945.042263] el1_sync_handler+0x64/0xe8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.042625] el1_sync+0x84/0x140 Aug 31 09:31:27 rockpi-s kernel: [ 1945.042942] clear_page_dirty_for_io+0x38/0x278 Aug 31 09:31:27 rockpi-s kernel: [ 1945.043374] mpage_submit_page+0x30/0xa0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.043753] mpage_map_and_submit_buffers+0x168/0x2a8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.044225] ext4_writepages+0x748/0xc38 Aug 31 09:31:27 rockpi-s kernel: [ 1945.044601] do_writepages+0x58/0x100 Aug 31 09:31:27 rockpi-s kernel: [ 1945.044960] __writeback_single_inode+0x44/0x508 Aug 31 09:31:27 rockpi-s kernel: [ 1945.045398] writeback_sb_inodes+0x1e0/0x478 Aug 31 09:31:27 rockpi-s kernel: [ 1945.045804] __writeback_inodes_wb+0x78/0xe8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.046209] wb_writeback+0x26c/0x400 Aug 31 09:31:27 rockpi-s kernel: [ 1945.046563] wb_workfn+0x310/0x5f8 Aug 31 09:31:27 rockpi-s kernel: [ 1945.046897] process_one_work+0x1ec/0x4d0 Aug 31 09:31:27 rockpi-s kernel: [ 1945.047296] worker_thread+0x48/0x478 Aug 31 09:31:27 rockpi-s kernel: [ 1945.047648] kthread+0x140/0x150 Aug 31 09:31:27 rockpi-s kernel: [ 1945.047963] ret_from_fork+0x10/0x34 Aug 31 09:31:27 rockpi-s kernel: [ 1945.048302] ---[ end trace cdc066846165d222 ]---
  6. I make apt full-upgrade after apt-update, but many - many errors: ip not found & ignore for packets. Make apt-get autoclean, but nothing... apt-get autoclean Чтение списков пакетов… Готово Построение дерева зависимостей Чтение информации о состоянии… Готово apt full-upgrade Чтение списков пакетов… Готово Построение дерева зависимостей Чтение информации о состоянии… Готово Расчёт обновлений… Готово Следующие пакеты устанавливались автоматически и больше не требуются: libdrm-freedreno1 libf2fs0 libllvm6.0 Для их удаления используйте «apt autoremove». Следующие НОВЫЕ пакеты будут установлены: android-libboringssl android-libcrypto-utils libf2fs-format4 libf2fs5 libllvm8 libmaxminddb0 libwayland-egl1 python3-netifaces Следующие пакеты будут обновлены: adb android-libadb android-libbase android-libcutils android-libf2fs-utils android-liblog apt apt-transport-https apt-utils armbian-config curl f2fs-tools firefox firefox-locale-ru hostapd htop libapt-inst2.0 libapt-pkg5.0 libarchive13 libcogl20 libcurl3-gnutls libcurl4 libgl1-mesa-dri libgtk-3-0 libnss-myhostname libnss-systemd libpam-systemd libpython2.7 libpython2.7-minimal libpython2.7-stdlib libpython3.6 libpython3.6-minimal libpython3.6-stdlib libsdl2-2.0-0 libsoup-gnome2.4-1 libsoup2.4-1 libsystemd0 libudev1 libwayland-egl1-mesa linux-libc-dev netplan.io python2.7 python2.7-minimal python3.6 python3.6-minimal systemd systemd-sysv udev wireshark-common wireshark-qt Обновлено 50 пакетов, установлено 8 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено. Необходимо скачать 83,2 MB/87,1 MB архивов. После данной операции объём занятого дискового пространства возрастёт на 127 MB. Хотите продолжить? [Д/н] y Игн:1 http://ports.ubuntu.com bionic-security/main armhf libnss-systemd armhf 237-3ubuntu10.29 Игн:2 http://ports.ubuntu.com bionic-security/main armhf libsystemd0 armhf 237-3ubuntu10.29 Игн:3 http://ports.ubuntu.com bionic-security/main armhf libnss-myhostname armhf 237-3ubuntu10.29 Игн:4 http://ports.ubuntu.com bionic-security/main armhf libpam-systemd armhf 237-3ubuntu10.29 Игн:5 http://ports.ubuntu.com bionic-security/main armhf systemd armhf 237-3ubuntu10.29 Игн:6 http://ports.ubuntu.com bionic-security/main armhf udev armhf 237-3ubuntu10.29 Игн:7 http://ports.ubuntu.com bionic-security/main armhf libudev1 armhf 237-3ubuntu10.29 Игн:8 http://ports.ubuntu.com bionic-security/main armhf systemd-sysv armhf 237-3ubuntu10.29 Ошб:9 http://ports.ubuntu.com bionic-updates/main armhf libapt-pkg5.0 armhf 1.6.12 404 Not Found [IP: 91.189.88.152 80] Ошб:10 http://ports.ubuntu.com bionic-updates/main armhf libapt-inst2.0 armhf 1.6.12 404 Not Found [IP: 91.189.88.152 80] Ошб:11 http://ports.ubuntu.com bionic-updates/main armhf apt armhf 1.6.12 404 Not Found [IP: 91.189.88.152 80] Ошб:12 http://ports.ubuntu.com bionic-updates/main armhf apt-utils armhf 1.6.12 404 Not Found [IP: 91.189.88.152 80] Игн:13 http://ports.ubuntu.com bionic-security/main armhf libpython3.6 armhf 3.6.8-1~18.04.2 Игн:14 http://ports.ubuntu.com bionic-security/main armhf python3.6 armhf 3.6.8-1~18.04.2 Игн:15 http://ports.ubuntu.com bionic-security/main armhf libpython3.6-stdlib armhf 3.6.8-1~18.04.2 Игн:16 http://ports.ubuntu.com bionic-security/main armhf python3.6-minimal armhf 3.6.8-1~18.04.2 Игн:17 http://ports.ubuntu.com bionic-security/main armhf libpython3.6-minimal armhf 3.6.8-1~18.04.2 Игн:18 http://ports.ubuntu.com bionic-security/main armhf libpython2.7 armhf 2.7.15-4ubuntu4~18.04.1 Игн:19 http://ports.ubuntu.com bionic-security/main armhf python2.7 armhf 2.7.15-4ubuntu4~18.04.1 Игн:20 http://ports.ubuntu.com bionic-security/main armhf libpython2.7-stdlib armhf 2.7.15-4ubuntu4~18.04.1 Игн:21 http://ports.ubuntu.com bionic-security/main armhf python2.7-minimal armhf 2.7.15-4ubuntu4~18.04.1 Игн:22 http://ports.ubuntu.com bionic-security/main armhf libpython2.7-minimal armhf 2.7.15-4ubuntu4~18.04.1 Ошб:23 http://ports.ubuntu.com bionic-updates/main armhf netplan.io armhf 0.97-0ubuntu1~18.04.1 404 Not Found [IP: 91.189.88.152 80] .............................................................. E: Не удалось получить http://ports.ubuntu.com/pool/universe/w/wireshark/wireshark-qt_2.6.8-1~ubuntu18.04.0_armhf.deb 404 Not Found [IP: 91.189.88.152 80] E: Не удалось получить некоторые архивы; возможно, нужно запустить apt-get update или попытаться повторить запуск с ключом --fix-missing? armbianmonitor -u ### Installed packages: ii armbian-config 5.95 all Armbian configuration utility ii armbian-tools-bionic 5.75 armhf Armbian tools, Cubie bt utils ii hostapd 3:2.7-99~armbian5.86+1 armhf IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator ii linux-base 4.5ubuntu1 all Linux image base package ii linux-bionic-root-next-orangepiplus2e 5.90 armhf Armbian tweaks for bionic on orangepiplus2e (next branch) ii linux-dtb-next-sunxi 5.92 armhf Linux DTB, version 4.19.62-sunxi ii linux-image-next-sunxi 5.92 armhf Linux kernel, version 4.19.62-sunxi ii linux-libc-dev:armhf 4.15.0-60.67 armhf Linux Kernel Headers for development ii linux-u-boot-orangepiplus2e-next 5.90 armhf Uboot loader 2019.04 ii sunxi-tools 1.4.2-2~armbian5.86+1 armhf tools for working with Allwinner (sunxi) ARM processors
  7. @tkaiser could you rerun the ext4 vs. f2fs tests with the latest version of Armbian? Perhaps somebody can offer f2fs image builds so many people can test it, as is being done for https://github.com/RPi-Distro/pi-gen/issues/471#issuecomment-732223791
  8. After checking, /var/log/armbian-hardware-monitor.log I detected btrfs did not exist in my build. I went back to lib/configuration.sh and saw btrfs-progs package was not installed if BUILD_MINIMAL = YES. if [[ "$BUILD_MINIMAL" != "yes" ]]; then # Essential packages PACKAGE_LIST="$PACKAGE_LIST bridge-utils build-essential fbset \ iw wpasupplicant sudo linux-base crda \ wireless-regdb unattended-upgrades \ console-setup unicode-data initramfs-tools \ ca-certificates expect iptables automake html2text \ bison flex libwrap0-dev libssl-dev libnl-3-dev libnl-genl-3-dev keyboard-configuration" # Non-essential packages PACKAGE_LIST_ADDITIONAL="$PACKAGE_LIST_ADDITIONAL alsa-utils btrfs-progs dosfstools iotop stress screen \ ntfs-3g vim pciutils evtest pv libfuse2 libdigest-sha-perl \ libproc-processtable-perl aptitude dnsutils f3 haveged hdparm rfkill vlan bash-completion \ hostapd git ethtool unzip ifenslave libpam-systemd iperf3 \ software-properties-common libnss-myhostname f2fs-tools avahi-autoipd iputils-arping qrencode sunxi-tools" fi I changed then this from PACKAGE_LIST="bc cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \ ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \ nocache debconf-utils python3-apt" to PACKAGE_LIST="bc btrfs-progs cpufrequtils device-tree-compiler fping fake-hwclock psmisc chrony parted dialog \ ncurses-term sysfsutils toilet figlet u-boot-tools usbutils openssh-server \ nocache debconf-utils python3-apt" And now it works. I suppose btrfs-progs needs to be added to PACKAGE_LIST (or DEBOOTSTRAP_LIST?) only in the case ROOTFS_TYPE=btrfs and irrespectively of BUILD_MINIMAL.
  9. Focal / root on eMMC / ZFS on hdd / LXD / Docker I received my Helios64 yesterday, installed the system, and decided to write down my steps before I forget them. Maybe someone will be interested. :-) Preparation: Assembly your box as described here. Download Armbian Focal image from here and flash it to SD card. You may use Ether. Insert the SD card to your Helios64 and boot. After 15-20s the box should be accessible via ssh. (Of course you have to find out it's IP address somehow. For example check your router logs or use this.) First login: ssh root@IP Password: 1234 After prompt - change password and create your daily user. You should never login as root again. Just use sudo in the future. :-) Note: The auto-generated user is member of "disk" group. I do not like it. You may remove it so: "gpasswd -d user disk". Now move your system to eMMC: apt update apt upgrade armbian-config # Go to: System -> Install -> Install to/update boot loader -> Install/Update the bootloader on SD/eMMC -> Boot from eMMC / system on eMMC You can choose root filesystem. I have chosen ext4. Possibly f2fs might be a better idea, but I have not tested it. When finished - power off, eject the sd card, power on. Your system should now boot from eMMC. If you want to change network configuration (for example set static IP) use this: "sudo nmtui". You should also change the hostname: sudo armbian-config # Go to: Personal -> Hostname ZFS on hard disk: sudo armbian-config # Go to Software and install headers. sudo apt install zfs-dkms zfsutils-linux # Optional: sudo apt install zfs-auto-snapshot # reboot Prepare necessary partitions - for example using fdisk or gdisk. Create your zfs pool. More or less this way: sudo zpool create -o ashift=12 -m /mypool -mypool mirror /dev/disk/by-partuuid/abc123 /dev/disk/by-partuuid/xyz789 Reboot and make sure the pool is imported automatically. (For example by typing "zpool status".) You should now have working system with root on eMMC and ZFS pool on HDD. Docker with ZFS: Prepare the filesystem: sudo zfs create -o mountpoint=/var/lib/docker mypool/docker-root sudo zfs create -o mountpoint=/var/lib/docker/volumes mypool/docker-volumes sudo chmod 700 /var/lib/docker/volumes # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/docker-root sudo zfs set com.sun:auto-snapshot=true mypool/docker-volumes Create /etc/docker/daemon.json with the following content: { "storage-driver": "zfs" } Add /etc/apt/sources.list.d/docker.list with the following content: deb [arch=arm64] https://download.docker.com/linux/ubuntu focal stable # deb-src [arch=arm64] https://download.docker.com/linux/ubuntu focal stable Install Docker: sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io #You might want this: sudo usermod -aG docker your-user Voila! Your Docker should be ready! Test it: "docker run hello-world". Option: Install Portainer: sudo zfs create rpool/docker-volumes/portainer_data # You might omit the above line if you do not want to have separate dataset for the docker volume (bad idea). docker volume create portainer_data docker run -d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce Go to http://yourip:9000 and configure. LXD with ZFS: sudo zfs create -o mountpoint=none mypool/lxd-pool sudo apt install lxd sudo lxc init # Configure ZFS this way: Do you want to configure a new storage pool (yes/no) [default=yes]? yes Name of the new storage pool [default=default]: Name of the storage backend to use (dir, btrfs, ceph, lvm, zfs) [default=zfs]: zfs Create a new ZFS pool (yes/no) [default=yes]? no Name of the existing ZFS pool or dataset: mypool/lxd-pool [...] #You might want this: sudo usermod -aG lxd your-user # Option: If you use zfs-auto-snapshot, you might want to consider this: sudo zfs set com.sun:auto-snapshot=false mypool/lxd-pool sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/containers sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/custom sudo zfs set com.sun:auto-snapshot=true mypool/lxd-pool/virtual-machines That's it. Lxd should work now on ZFS. :-)
  10. jbergler

    Helios64 Support

    If you, like myself, installed on eMMC and are experiencing the crashes on 20.08.14 - I booted up via a 20.08.10 sdcard and fixed the environment on emmc # mount the emmc + get ready to chroot mkdir /mnt/chroot mount /dev/mmcblk1p2 /mnt/chroot/ mount /dev/mmcblk1p1 /mnt/chroot/media/mmcboot mount --bind /mnt/chroot/media/mmcboot/boot/ /mnt/chroot/boot/ mount --bind /dev /mnt/chroot/dev/ mount --bind /proc /mnt/chroot/proc/ mount --bind /tmp /mnt/chroot/tmp/ # chroot in and downgrade to 20.08.10 chroot /mnt/chroot/ /bin/bash apt install \ linux-dtb-current-rockchip64=20.08.10 \ linux-headers-current-rockchip64=20.08.10 \ linux-image-current-rockchip64=20.08.10 \ armbian-config=20.08.10 \ armbian-firmware=20.08.10 \ linux-focal-root-current-helios64=20.08.10 \ linux-u-boot-helios64-current=20.08.10 exit # now remove the sd card and hit reset @aprayoga It's probably unrelated, but while working through the above I noticed that I ran out of space on /boot. I installed to eMMC the first version that was working, if that helps. I chose f2fs when I installed on eMMAC and this is the resulting partition layout mmcblk1 179:32 0 14.6G 0 disk ├─mmcblk1p1 179:33 0 96M 0 part └─mmcblk1p2 179:34 0 14.3G 0 part mmcblk1boot0 179:64 0 4M 1 disk mmcblk1boot1 179:96 0 4M 1 disk Sadly I didn't grab enough info from what was in the boot partition before I nuked it and reinstalled the appropriate packages.
  11. flower

    Helios64 Support

    only through a fresh install? i would have preferred f2fs. for flash memory it has a way better durability. anyway... thank you. i wont write much there anyway - all data is in docker volumes on hdd
  12. Sorry for a newbie question. I am setting up a raid system based on flash drives on a Orange Pi One and every thing is working fine. I am now thinking of moving from ext4 for F2FS but I can't figure out how to get it to work. I have installed f2fs-tools and managed to format the drive but I can't seem to mount it. I can't seem to run "modprobe f2fs". Does this mean that I need to recombile the kernel or what? I am not intending to boot from f2fs. Just mount the raid system for storage.
  13. @guidol - no, while this may seem weird it's perfectly normal - this is a "bind mount", and this is how bind mounts appear in "mount". You can create one of these yourself, for example: root@nanopi:~# mkdir foo bar root@nanopi:~# mount --bind foo bar root@nanopi:~# mount | grep bar /dev/mmcblk1p2 on /root/bar type f2fs (rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2) root@nanopi:~# (The "log.hdd" bind mount is created via "/usr/lib/armbian/armbian-ramlog".) Hope this helps!
  14. @Adrian Cable - I made the changes for sunxi-current and pushed to the repo: https://github.com/armbian/build/commit/b2adb2935b4dcee57c982a1447de8cf75760dd2a. This change adds a new boot overlay for the sun8i-h3 that enables a maximum of 1.3GHz at a CPU core voltage of 1.3v. If you use this overlay, I strongly recommend you try driving the board hard to ensure stability (e.g., "stress --cpu 4", etc.) Historically on most of my boards the maximum I could push to was 1.2GHz at 1.3v, which is why I added a 1.2GHz overlay for the H5 (and I could only get to 1.368GHz w/a 1.4v core voltage). I can do the same for the H3, but am short on time atm. I'll also add this overlay to sunxi-legacy as well, but I won't be able to get to this later. I tested this on one of my H3 boards w/a max CPU voltage of 1.3v: /boot/armbianEnv.txt (note the addition of "cpu-clock-1.3GHz-1.3v" to the "overlays=" line): verbosity=7 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost1 usbhost2 uart1 cpu-clock-1.3GHz-1.3v rootdev=UUID=3ad712a7-75cb-4ac1-8cfa-dbb67df8f239 rootfstype=f2fs extraargs=net.ifnames=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u After booting with this overlay, from "cpufreq-info", w/everything else at the defaults, maximum clock rate is now 1.30GHz: analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 5.44 ms. hardware limits: 480 MHz - 1.30 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:96.94%, 648 MHz:0.35%, 816 MHz:0.04%, 960 MHz:0.03%, 1.01 GHz:0.03%, 1.06 GHz:0.02%, 1.10 GHz:0.02%, 1.15 GHz:0.03%, 1.20 GHz:0.02%, 1.22 GHz:0.01%, 1.25 GHz:0.01%, 1.30 GHz:2.50% (253) Please give this a try and let me know how it goes If 1.3GHz is unstable, I'll try to expedite adding the 1.2GHz overlay as well.
  15. What to do to switch from ext4 to F2FS (one big caveat: Partition/filesystem resizing doesn't work with F2FS so this is only for you if you know the size of your SD card prior to building the image)? I tried the following so far: apt-get install f2fs-tools define size of f2fs partition in compile.sh (eg. for a 4 GB SD card use »SDSIZE="3600"«) adjust »BOOTSIZE=16« in lib/configuration.sh (line 26) replace »mkfs.vfat -n "$IMAGEVOLUME"« with »mkfs.ext4 -q« in lib/deboostrap.sh (line 66) replace »mkfs.ext4 -q« with »mkfs.f2fs« in lib/deboostrap.sh (line 67) add »-tf2fs« to mount option in lib/deboostrap.sh (line 68) comment »shrinking_raw_image "$DEST/output/$VERSION.raw"« out in lib/common.sh (line 463) change fstab entry to »echo "/dev/mmcblk0p2 / f2fs defaults,noatime,nodiratime,errors=remount-ro 0 0" >> $DEST/output/sdcard/etc/fstab« in lib/distributions.sh (line 105) comment »install -m 755 $SRC/lib/scripts/resize2fs $DEST/output/rootfs/$CHOOSEN_ROOTFS/etc/init.d« out in lib/distributions.sh (line 138) avoid partition resizing on first run by removing lines 89-101 in lib/scripts/firstrun But the Banana Pro I test with doesn't boot. I would assume that I have to modify boot.cmd (and exchange /boot/ with /)? Thx
  16. Hi, just a question to be discussed: Would it... 1. ...be possible to use F2FS as default filesystem for images using the vanilla kernel? 2. ...make sense to use it? benchmarks show that write operations could get a huge boost in comparison to ext4. i believe write operations are quite slow right now (using cubietruck with sd-card) What do you think?
  17. Suggested changes to general.sh 796 export LC_ALL="en_US.UTF-8" 797 798 # packages list for host 799 # NOTE: please sync any changes here with the Dockerfile and Vagrantfile 800 local hostdeps="wget ca-certificates device-tree-compiler pv bc lzop zip binfmt-support build-essential ccache debootstrap ntpdate \ 801 gawk gcc-arm-linux-gnueabihf qemu-user-static u-boot-tools uuid-dev zlib1g-dev unzip libusb-1.0-0-dev fakeroot \ 802 parted pkg-config libncurses5-dev whiptail debian-keyring debian-archive-keyring f2fs-tools libfile-fcntllock-perl rsync libssl-dev \ 803 nfs-kernel-server btrfs-progs ncurses-term p7zip-full kmod dosfstools libc6-dev-armhf-cross \ 804 curl patchutils liblz4-tool libpython2.7-dev linux-base swig aptly acl python3-dev \ 805 locales ncurses-base pixz dialog systemd-container udev lib32stdc++6 libc6-i386 lib32ncurses5 lib32tinfo5 \ 806 bison libbison-dev flex libfl-dev cryptsetup gpgv1 gnupg1 cpio aria2 pigz dirmngr python3-distutils \ 807 ccache aria2 libusb-1.0-0-dev" 808 809 local codename=$(lsb_release -sc) 810 When I get my build environment working, and can adequately test, I'll submit this as a pull request. Harry
  18. I doubt it can be done easily : U-Boot is not aware of F2FS, so it requires that at least the /boot folder to be located in EXT4 or FAT partition. What you can do is to manually shrink the ROOTFS partition and then add a new partition that you will format as F2FS. Then, you can transfer ROOTFS contain to new F2FS partition using tools such "rsync" or "tar|tar", and leave the /boot folder, adjust both /boot/armbianEnv.txt and /etc/fstab to point ROOTFS to the new F2FS.
  19. I have never tried it. I am running it from SD card. That way it is much easier to manage. microSD cards cost so little these days. Just make sure you pick up a good one, like Sandisk Extreme (Pro), Samsung Pro or something like that. Samsung Evo+ is not too bad either. Generic cards, like cheap Kingston ones, are extremely slow. Specially when dealing with lot of small files. If you try to extract something like linux source or headers, which contain lot of small files, it takes ages. Goods cards have much higher IOPS and work quite well. Class 10, UHS-I and other markings are quite useless. The most important number is IOPS. Higher IOPS means much better performance when running OS on it. You can not find official IOPS specification for any cards. But internet is full of benchmarks and for some cards that information can be found unofficially. When booting kernel looks for partition labeled ROOTFS to mount as "/" and it can be on any storage device visible to kernel. So you can put it on USB stick or external HDD or any other device kernel recognizes, including emmc. I am not sure if it works but in theory you could partition mmcblk2 (I think it is emmc on our box), make one ext4 (or maybe f2fs) partition on it and label it ROOTFS (or anything else but then you need to update boot files accordingly). Copy entire SDcard contents there (except /boot, /sys, /proc, /dev - just make empty directories). If you labeled your partition ROOTFS then relabel your SD partition to something else. So you have only one partition labeled ROOTFS. After reboot you should boot from emmc. Then your boot partition remains on SD card but everything else is on emmc. You still need SD card to boot but entire system except kernel (which is only read once when booting) will be on emmc. And that SD card can be any old slow card. I think I would try something like that. I do not know if emmc contains something important for booting. If you completely erase it and re-partition you might make your box unbootable/(soft)bricked. So in theory it will work. But if emmc contains something important for booting, it will not. You will not see Android partitions on emmc because Android does not use partition table. Android uses partition definition file or something like that. That is essentially external partition table stored somewhere else. So linux kernel and partition tools know nothing about existing partitions because emmc has no partition table and looks like empty - but it is not. About DTB... I think I tried meson-g12a-x96-max.dtb and meson-g12a-x96-max-rmii.dtb but I do not think either one worked. If I remember correctly I tried all g12a DTB files but only one worked. Do you have BT and/or WiFi working? I do not care much about WiFi (I use cable anyway) but BT would be good - I could use keyboard/mouse without external dongle. EDIT: meson-g12a-x96-max.dtb and meson-g12a-x96-max-rmii.dtb do not work on my box. Tried both. Mecool KM9, 4GB RAM, 32GB ROM, 1Gb ethernet, S905x2 CPU
  20. @tkaiser From what I have seen performance is similar to ext4 and not sure if it still suffers the level of performance degradation over time that it once had. Just wondering if you Armbian guys ever did any tests on block wear vs ext4 as just wondering as never really seen many real world examples. In a way f2fs should take a dumb old cheap sd card and use the boards cpu to provide a high level wear levelling algs & process with over-provision. Not really sure aside from the perf tests how you can capture the block wear as a comparison however.
  21. I got a similar issue, but i got solved by trying different things. Before we got this issue, I was installing the armbian to emmc with the fs f2fs. When I installed with f2fs sometimes I had to rebooted the several times to boot or sometimes it is not boot. Then I tried with ext3 and it works perfect. I hope I help you.
  22. Greetings to all, Preamble: Thanks to all that have worked to make the Armbian project what it is today. It is greatly appreciated! I have done numerous hours of reading and searching (due diligence). I know I could run a benchmarks and all but that means even more delay reaching the objective. Some brief guidance from those who have gone before would save a lot of time and would be greatly appreciated. Looking at the datasheets wasn't real helpful in guesstimating optimum performance configuration - especially since there are so many other factors that have an impact. Background: My objective is to achieve a reliable, long life system and avoid big performance hits along the way. The host is for home automation so the most of the storage activity will be logging and playing back canned sounds and serving up web pages consistent with HMI functions by my estimation. Other activity will be from Node-Red, MQTT broker, The automation web server, etc. I also maintain a NAS in the house so logs backups and databases associated with the HA system will be copied or backed up there. I have done so much reading and a fair bit of testing that I am a bit unsure as I write if Armbian supports logging to ramdisk or some such. If so, this would also be part of the picture for me. I would either sense the UPS power state or come up with a supercap or other power storage scheme and sense power loss and push ramdisk to NV storage... This is a little off topic but is relevant to the extent that I don't want to loose data that has been collected and the safest place for it is not in ram but in flash. I am guessing that for this context with a limited number (15?) of devices connected to via browser such as tablets, phones, and PCs alongside a few dozen other devices that are I/O nodes, not a lot of disk I/O will be needed. Room for growth is important (I hope) as well as avoiding performance degradation as a consequence of it. It is troublesome to have to deal with 'users' noticing slowdowns! Though of course I wouldn't consider hobbling the system now and loosening the reins later to deal with extra load... As I see it, if I use eMMC at all, I need to be using some kind of wear leveling (f2fs), minimize writes to it, and don’t fill it too full. A better option if performance will allow is to use sda1 instead for the root file system. I assume the M.2 device will have wear leveling and other features which along with much larger capacity (largely empty) in concert with brtfs file system is the best I can do to get performance and reliable operation over the M.2 /USB interface. Since M.2 is replaceable it is reasonable to expect that the system will not become permanently unusable due to flash wear failures in the near and mid term - I can simply restore to new M.2 device if it fails. Long term fiscal and technology issues are another matter. Question 1: Which would yield a more responsive system? The os residing on the eMMC or M.2? I see that the eMMC is using an 8 bit parallel interface (data and address must be using same path) vs the M.2 slot which is connected via a JMS567-LGBB1A chip. I read here https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350 that it at least has the potential to be a good performer. The context there was USB3 which is not used on the FA shield. The shield uses USB2 so there is still some question about how it will perform (there are other factors as well of course). Question 2: If I end up using eMMC for root, and assuming logs are being written to m.2, what recommendations to monitor and make sure writes to eMMC are minimized? I would probably want to do some monitoring anyway later on for lots of reasons. Pointers on how to set up brtfs (f2fs as well actually) for root to maintain speed and health in this context would also be appreciated. Regards and thanks again to all that have and will contribute, Q
  23. Preamble: I have done numerous hours of reading and searching (due diligence). See end. I have a FA NanoPi NEO Core-2 LTS with shield and 64G M.2 (This shield uses JMS567-LGBB1A chip USB to sata for M.2 access). I have successfully installed Armbian from SD to and booted from the eMMC. Armbian Stretch mainline kernel 4.14.y - This image https://dl.armbian.com/nanopineocore2/Debian_stretch_next.7z armbianmonitor -u results http://ix.io/1xAA Logs indicate formatting did occur correctly as far as I can tell. The volumes are formatted as I selected - along with an 'extra' ext4 volume that looks like it is just for boot. NOTE: Since I could not boot, I re-tried using default ext4 for both which works. System now boots Armbian without TF. ATM OS resides on sda1. Console output: INFO: PSCI Affinity Map: INFO: AffInst: Level 0, MPID 0x0, State ON INFO: AffInst: Level 0, MPID 0x1, State ON INFO: AffInst: Level 0, MPID 0x2, State ON INFO: AffInst: Level 0, MPID 0x3, State ON U-Boot SPL 2018.05-armbian (Oct 27 2018 - 08:32:18 +0200) DRAM: 1024 MiB Trying to boot from MMC2 NOTICE: BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):c9f55c0 NOTICE: BL3-1: Built : 08:32:12, Oct 27 2018 NOTICE: DT: sun50i-h5-nanopi-neo-core2 NOTICE: SCPI: dummy stub handler, implementation level: 000000 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2018.05-armbian (Oct 27 2018 - 08:32:18 +0200) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: FriendlyARM NanoPi NEO Core 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from EXT4... MMC: no card present ** Bad device mmc 0 ** Failed (-5) In: serial Out: serial Err: serial Net: No ethernet found. MMC: no card present ** Bad device mmc 0 ** MMC: no card present ** Bad device mmc 0 ** starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3090 bytes read in 4 ms (753.9 KiB/s) ## Executing script at 4fc00000 U-boot loaded from eMMC or secondary SD Boot script loaded from mmc 208 bytes read in 2 ms (101.6 KiB/s) MMC: no card present ** Bad device mmc 0 ** 30102 bytes read in 11 ms (2.6 MiB/s) 504 bytes read in 17 ms (28.3 KiB/s) Applying kernel provided DT overlay sun50i-h5-usbhost1.dtbo 504 bytes read in 14 ms (35.2 KiB/s) Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo 4179 bytes read in 13 ms (313.5 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 4923549 bytes read in 247 ms (19 MiB/s) 13148168 bytes read in 649 ms (19.3 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 4923485 Bytes = 4.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Loading Ramdisk to 49b4d000, end 49fff05d ... OK reserving fdt memory region: addr=4fa00000 size=6d000 Loading Device Tree to 0000000049add000, end 0000000049b4cfff ... OK Starting kernel ... Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.29.2 done. mount: Invalid argument done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: No such file or directory mount: invalid option -- done. mount: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 No init found. Try passing init= bootarg. Rebooting automatically due to panic= boot argument To elaborate on the process, after writing TF card and booting, I ran armbian-config selecting option "eMMC boot | USB/SATA/NVMe root install" and selected format of btrfs for sda1. Also, "Select filesystem type for eMMC /dev/mmcblk2" ... "Formating /dev/mmcblk2 to f2fs ... please wait". The utility responded with the appropriate warnings (about erasing/formatting) and appeared to execute correctly, returning no errors and prompting for reboot at end of process. I shutdown, removed card, powered up and system did not come up properly. I saw no special advisories about additional manual steps etc. Question: Did I miss a step when using the alternative disk format options on this platform? Are they a WIP? Should I file a bug report? 'Bibliography:' https://docs.armbian.com/User-Guide_Getting-Started/ https://docs.armbian.com/User-Guide_Armbian-Config/ Nearly all NanoPi NEO2 forum posts here Many others...
  24. vm.swappiness=100 https://ghostbin.com/paste/vrt5t With vm.swappiness=30: system work fine With wm.swappiness=100: system work fine for a random time (3-12 h), then hang with ssh unreachable, yellow ethernet led fixed on, pihole/motioneye/rpi monitor web pages unreachables. Hardware: OrangePI Zero v1.4 - Sandisk uSD 16GB U1 A1 (checked, good healt) EXT4 - Toshiba USB Stick 32GB (checked, good healt) F2FS, USB PSU FriendlyARM 5V/3A (checked, good healt).
  25. These are two different questions. The media makes no difference whatsoever if it's about booting times, even most crappy SD cards perform the same: https://forum.armbian.com/topic/4167-f2fs-revisited/?do=findComment&amp;comment=30835 If you for whatever reasons need short boot times Armbian is not for you. We optimize constantly but never for short boot times but for better operation once the board has finished booting If you need short boot times you need to become an expert to learn how to eliminate the various bottlenecks (see https://forum.armbian.com/topic/1089-usbootpi/ for example) If you're interested in times relevant for your use case you need to measure the time until the respective service is usable (and not until a login prompt appears somewhere).
×
×
  • Create New...