Jump to content

timonoj

Members
  • Posts

    22
  • Joined

  • Last visited

Posts posted by timonoj

  1. Ok. I am now considering to move to a more recent kernel. Searching linux-image I can see there's a linux-image-current-sunxi which should kick it to 5.12.12-sunxi edge, for which I believe there are headers. Is this kernel going to work with my banana pi M1? Anything I should be aware of? As mentioned, my main fear is the Banana not coming back online, for which I have very little way to fix it anytime soon, given the pandemic.

  2. So...I'm trying to find the linux headers for my Banana Pi M1, so I can install Wireguard on it. But seems there's no sanxi headers? Also...no headers for that kernel whatsoever.  The generic ones stop at 4.18 then jump to 5.0. Then there's a bunch of raspi and raspi2 headers, and then the misterious to me linux-headers-edge-sunxi 21.05.6, which I guess won't work on mine. Where should I get headers for my Banana Pi?

     

    Also just in case, I'm a bit worried about doing something too drastic, since this little thingy is located in another continent. Thanks!

  3. Just keep it simple. If you don't like SDcards or HDDs you could also use fast USB3 nano flash drives. In case you'd rather use network storage, use NFS as per

     

     

     

    Good luck.

    Thanks Rodolfo. Yeah, I'd consider that as an option...or maybe even a tiny SSD. But I'd really like the way of complex now, way easier maintenance later. After all, I'm having these trouble due to having it very easy on the go setup before...that I now need to completely change. If I get the iSCSI going, I can get easy snapshots and backups on the go, plus some other benefits, like expandable storage anytime I want, without even rebooting the Banana. This Banana is/will be handling all my personal cloud (seafile), backups and some other tasks...I want it running with the less maintenance possible once it works.

     

    Ok, so this is a failure, but an encouraging one:

     

    H5ZXuOX.jpg

     

     

    It's really reaching my NAS, but at the wrong path. The NAS specifies a fie bananapi.scr, and the path should be tftp_root/bananapi. There's a tftp_root/pxelinux.cfg with a working default file that launches a menu for different x86/x64 distros (only a testing live ubuntu at the moment). Not sure why it goes to pxelinux.cfg path if I didn't ask it to.

     

    The SD's boot.cmd is:

     

    ipaddr 192.168.0.5

    tftp 0x00000000 192.168.0.10:bananapi/bananapi.scr

    source 0x0000000

     

     

    And then the more complete boot.cmd at the tftp_root/bananapi goes as follows:

     

     

    ipaddr 192.168.0.5

    setenv bootargs "mem=384M@0M mem=512M@512M nvmem=128M@384M vmalloc=248M console=ttyS0,115200n8 rw root=/dev/sdc1

    netroot=iscsi:@192.168.0.10::::iqn.2004-04.com.qnap:ts-431:iscsi.armbian.000001 iscsi_initiator=iqn.2004-04.com.qnap:ts-431:iscsi.armbian.000001 ifname=eth0:xx:xx:xx:xx:xx:xx ip=eth0:192.168.0.5 nohdparm rootwait earlyprintk rd_NO_PLYMOUTH"

    tftp 4080000 192.168.0.10:bananapi/uImage

    tftp 4400000 192.168.0.10:bananapi/uInitrd-iscsi

    bootm 4080000 4400000

     

     

    Now to be honest, I'm not sure if it got stuck at the SD's boot.cmd or it managed to reach the second one. I think it's the first. It then fails to get the IP, not sure why and goes to get dhcp anyway. It doesn't look too bad to start with.

     

    EDIT: Well it seems to reach the bananapi/bananapi.scr path, as that's the transfer seen at the top of the screen "17.6 KiB/s, Done". With a dhcp IP instead of the one I tried setting, so I guess that command is wrong. Then it fails with the misaligned operation, which I have no clue how to fix, and then goes rambling around trying to find any other script. Not sure why it doesn't stick to the bananapi.scr.

  4. Ok...This is a bit over what I've done before so far.

    I found several guides more, like this one (for x86), and this other one, the most promising so far, for a Raspberry, using uboot and all. So far I dumped the working SD contents to the iSCSI target. And I have a working TFTP I can reconfigure in a minute to point somewhere else. However I'm a bit confused on editing the boot.cmd:

     

    Setting up your uboot scripts

    There are two places you need to make new uboot scripts. First, the trimslice itself needs a small uboot script that converts the existing uboot to tftpboot. You can replace the uboot in NAND if you like, but it's easier to just plug a small slow SD card in with just a boot script:

    /boot//boot/boot.cmd/boot/boot.scr

    The boot.cmd contains the following commands:

    dhcptftp 0x43f0000 ${dnsip}:trimslice/trimslice.scrsource 0x43f0000

    The command to convert the .cmd to a .scr is:

    mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Trim Slice boot script" -d boot.cmd boot.scr

    All this script does is use DHCP to configure its network interface, then connect to the DHCP server's TFTP to fetch yet another uboot script to run. In the TFTP area, we create another uboot script that looks like this (fill in your own MAC address, and any other specific kernel parameters you need):

    dhcpsetenv bootargs "mem=384M@0M mem=512M@512M nvmem=128M@384M vmalloc=248M console=ttyS0,115200n8 rw root=/dev/sdc1netroot=iscsi:@192.168.1.2::::dj.2011-12.com.delorie:sample.1 iscsi_initiator=dj.2011-12.com.delorie:sample.1 ifname=eth0:xx:xx:xx:xx:xx:xx ip=eth0:dhcp nohdparm rootwait earlyprintk rd_NO_PLYMOUTH"tftp 4080000 ${dnsip}:trimslice/uImagetftp 4400000 ${dnsip}:trimslice/uInitrd-iscsibootm 4080000 4400000

    While you're in there, copy the uImage and uInitrd-iscsi files from the SD card with your rootfs on it. Note that the tftp commands in the above uboot script need to match the file names you copy, whatever they are.

     

     

    My doubts here: How could I specify a fixed address in the uboot script instead of dhcp? As I want my banana to be a server, and I already have an IP for it. If the /etc/network/interfaces sets a different IP later on, I'm afraid I might get disconnected from the target.

     

    What's with this:
     

    tftp 0x43f0000 ${dnsip}:trimslice/trimslice.scr

    source 0x43f0000

     

     

    What does the 0x43f0000 mean, and should I change it for our bananas?

    Should I compile the /boot/boot.cmd in the SD exactly on that path while running from the banana? If anything fails, I don't get a do-over since it will no longer boot, right?

     

    Thanks!

  5. Hi guys!

     

    I'm embarking myself in a rather messy subject, as in, not very tested. I'd like to get rid as much as possible of the SD usage, and I don't want to use a local HDD either (wouldn't look neat where the Banana Pi sits). So...I'm trying an iSCSI target in a NAS!

    I'm trying to follow this guide, but I'm full of doubts. As the guide is designed for a normal computer, it reaches the point where it starts talking about GRUB. How do we perform boot on the Banana? Can anyone let me know where can I find documentation on the ARM boot process for armbian?

     

    Thanks!

  6. Yup, did that :D

    Unsupported by docker, and crashes. It didn't like it. Apparently NFS is not in their plans yet.

     

    EDID: Well apparently some dude managed to do it by modifying a bunch of things...here.

    https://whyistheinternetbroken.wordpress.com/2015/05/12/techusing-nfs-with-docker-where-does-it-fit-in/

     

    I might have to try that path, but it doesn't look like a piece of cake. At least all the nfs shares and client and autofs mounts are already there...

  7. Thanks, I might consider booting from PXE...Although that is way more complicated to setup I think, and messier to maintain. And the additional HDD...Sure that's an option, but I'd like to avoid having to purchase another HDD since I already have a NAS (hence my interest in iSCSI, the NAS sets those in almost just two clicks).

  8. At this moment zero, since I was doing a brand new install. During testing I tried a beta app that takes some 2.5GB on its own due to lack of dependencies polishing I think (Open365). Also Seafile deals with a huge amount of storage, but that one is happily taking a NFS mount point. Problem is, it's not very portable should I change the hardware or configuration on the OS (or OS completely, for that matter). I was thinking it to port it to a docker, but then again I'm facing the same trouble. Plus, any of these working on an SD would imply serious I/O whenever dealing with big chunks of files...I wouldn't trust it to keep the important data, just the system files. I'd prefer to even store the docker containers somewhere else. Safer.

     

    EDIT: Do you guys think it would be possible to mount EVERYTHING on a iSCSI target? Even the OS and boot from it? It would make snapshotting the whole OS a piece of cake.

  9. Hi guys,

    Given the not so great durability of SD cards (and limited storage...I try to keep everything on NFS mounts, but there's always some log that decides to randomly fill the SD card full of crap), and the incapability of run properly docker (it runs, but it NEEDS to use damn local storage, and won't take an NFS mount for some reason...it gets full real quick), I was considering to boot to a iSCSI target. This would let me expand storage anytime I need, plus it would make backup and snapshots a piece of cake. Is there a way to do this?

     

     

  10. ...aaaand it seems to get much further. But...still not. Stuck at "*Starting SSH Keys regeneration" for over 10 mins. Should I ssh into it?

     

     

     


    And does it then continue to boot after showing countless info, warnings or even errors or does booting stop?

     

    Yeah, it eventually crashed and stopped booting. It gave me an uboot prompt. But now it seems to load the kernel, although it still seems to be doing something...

  11. Hi guys,

     

    I'm getting this error while trying to boot my Banana Pi with an SD card.

     

    Hit any key to stop autoboot: 0
    switch to partitions #0, OK
    mmc0 is current device
    Scanning mmc 0:1...
    Found U-Boot script /boot/boot.scr
    2447 bytes read in 211 ms (10.7KiB/s)
    ##Executing script at 43100000
    Wrong image format for "source" command
    SCRIPT FAILED: Continuing...
    scanning bus for devices...
    Found 0 device(s).
     
    SCSI device 0:
             Device 0: not available
    [...]
    

     

    I'm coming from using Lubuntu with no problems for nearly a year. The SD card works no problem (or at least it worked perfectly fine with Lubuntu). I also tested with a way faster microSD 64GB I usually have in the GoPro, with the same result.

     

    What should I do to continue? I reckon this must be a n00b mistake, I must be missing something...

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines