Things went South after update

    Zitat von houndhunger

    I find out there are two micro USB connectors - one on short side next to SD card, one on long side next to SATA. I was using the one next to SD card

    It doesn't really matter which one you use unless you want to connect a SATA disk to be powered by the Banana itself since only the DC-IN Micro USB jack next to the SATA connector is directly connected to the SATA power port. Both Banana Pi and Pro are designed somewhat poorly compared to good A20 devices like Olimex Lime2 (here SATA disks are powered through the power management IC and are still spinning even if the board is running from battery).


    BTW: Swapping PSUs is absolutely useless if you don't take contact and cable resistance into account: http://www.cnx-software.com/20…-boards-or-charge-phones/ (99% of all USB cables suck since power wires too thin)


    Wrt 'read only filesystem': Your SD card is the culprit (quite common, even genuine ones die sooner or later). Do you use Etcher to flash the card or tools that don't do a verify?

    I use Etcher. That's why I believe SD card + written image on it should be coming out 100% for a start.


    The possible issue could be that micro USB connector on cable on previous power source was bended - I must hit it somehow recently while it was connected to Banana Pi...
    That is why I tried swapping power source and USB connection on Banana Pi to define what is wrong.
    I'll spend one more evening to define what exactly is wrong - SD card (3 cards will be tested) or Power source USB connection or Banana Pi USB connection.

    Zitat von Wolf2000

    Lach Lach

    https://forum.armbian.com/inde…-test-on-opi-zero-rev-14/


    Quoting TL Lim (Pine Inc founder) about their support issues with 18 months of selling Pine64 boards: 'More than 60% on the technical issue is on user not able to create a correct and useful microSD card build.' -- Guess why they only recommend and use Etcher in the meantime... (and guess why resin.io folks started to work on Etcher in the first place: since SD card crappiness is such an issue)

    I had long descriptive message prepared at home which I didn't sent because I got excited that I got things working... Until this morning when I restarted Banana Pi And it did not respond - no ping respond (waiting half hour, nothing).
    Yes I use Etcher - no error ever and flashed image is also right - OMV_3_0_71_Bananapi_4.10.11.7z (did checksum).
    I use SanDisk SD cards... I'll be happy to by Samsung EVO if you say so, just to stay out of this kind of problems. I found yesterday one with a problem. But the other seems right until now?...
    So, is there a tool where I can "stress-test" SD card because apparently working Update - Upgrade and no error on installed apps is NOT A TEST! I'm wasting my and your time here. Too much cowboy...
    So, I did couple restarts. Went OK last night, but not the one this morning. I was just going to restart it, turn it of and back it up... AGAIN! Hard to tell what is causing failing it because I did lot of settings.
    Also important to mention, I'm using some apps from testing repo? Like SFTP I think or fail2ban, what I can recall from my head it's in it.
    It might be helpful If I could see the output - HDMI visual - what is going on now as I can't get any response from Banana Pi.


    But first - How can I test SD card it's suitable for working Linux OS?

    Zitat von houndhunger

    How can I test SD card it's suitable for working Linux OS?

    In general you can and should test your SD card with either F3 or H2testw prior to usage. In Armbian it's also possible to run 'armbianmonitor -c $HOME' which is essentially a wrapper around f3 which provides you also with a performance report.


    Though we (Armbian community) have also reports about SD cards that survive these tests fine but fail reproducable with random IO patterns (apt upgrade or running


    Code
    iozone -e -I -a -s 1000M -r 16384k -i 0 -i 1 -i 2

    Since these OMV images are now based on Armbian you can also call nand-sata-install to move the installation to a partition of a connected disk or an USB thumb drive: https://docs.armbian.com/User-…all-to-emmc-nand-sata-usb


    But if you move the installation to a HDD be aware that spinning the disk down is not a good idea since it will wake up every now and then. So this is only an option if you want your disk always spinning. And even in case you used nand-sata-install the SD card has to remain where it is but is then only used for loading the bootloader on the first MB of the card and everything else then lives on disk or USB thumb drive (that's how I deal with broken SD cards that show errors)

    Zitat von ryecoaaron

    I was thinking we should target 16gb SD cards? I'm also fine with btrfs+compression.

    I went with 8GB now since releasing a new OMV image for XU4 later (testing). You can't get any good 4GB SD card these days (some really expensive industrial excluded) but some with 8GB exist (eg. I have two very fast SanDisk Extreme Pro with 8 GB each).


    The move to btrfs is a little bit postponed since I need to test through every currently supported board first (and I schedule one board per day max).

    nand-sata-install works. I think SD boot was causing some errors. It seems better now with USB.
    But something from testing repo is still causing it to stuck on something on reboot.
    I guess on more reinstall AGAIN and add one by plugins and restart each time to determine what is causing it. From my head what I can remember it could be sftp, sensors, fail2ban....
    On very beginning when I had OMV 3 version with HDMI on - this is what I could spot /camera-shot:

    I know it is old and has nothing to do with OMV image I'm using now, but for you it could be quick peak maybe, and possibly you'll spot something what is going on.
    In meantime, I start reinstalling...


    THANK YOU for past recommendations tkaiser.


    UPDATE: So after four lame hours: nand-sata-install, then I did update, done some basic setup for sharing(couple HDD share - samba + FTP, certificates, one user...). Then I have installed SFTP set it up and restarted... Server didn't boot back to have any response from it. (tried unplugging hdds ... nothing)


    Any thoughts?
    Tomorrow, I do it AGAIN but I won't touch any additional repo, just basic one, especially not SFTP. I'll see how it goes...

    Einmal editiert, zuletzt von houndhunger () aus folgendem Grund: non-progress update

    Half way there.
    I have found out that my luks encrypted partition - once shared folder on it is added to SFTP share, it will cause system not to boot (or in some early point braking - cannot access web interface nor ssh). Done - tested twice.
    SFTP installed and sharing other shared folder on un-encrypted partition will work OK, and on restart will Banana Pi - PC will boot then.
    Not issue with SAMBA. Can't remember FTP (not using it), if it got through.
    My pure logical guess based on occasions is that SFTP is in testing repo for a reason and it is braking booting proces somehow because encrypted partition is involved.


    Any idea, could it be solved? Can I pass it to somewhere else, so it could be solved?
    I just want to pass it to make my literally about 100 hours spent on this issue worth it.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden