Jump to content

Recommended Posts

Posted

Did you leave the microSD in after move? Booting directly from USB is not possible afaik but you can have the boot loader on sd which then boots from USB.

Posted (edited)

Yes, absolutely...I know the Orange Pi SBC's don't have the EEPROM capable of flashing to allow boot directly from the USB or EMMC like a RPi does

I did move the RPiPC to a screen and it starts loading but then hangs, have to log in with root pw to go into maintenance mode but would not boot from the USB drive that I just copied the root partition to

I really like having the boot partition on the SD and run from a USB because they are usually faster, but for some reason it hangs up...

I did re-flash the SD and everything is running from a 16GB Sandisk Ultra A1...but I want to copy the root to a very good Sandisk Ultra fit USB 64GB.  Then move the /home to a 1TB WD USB -> SATA adapter to put all the docker volumes in there
I know USB2 isn't the speediest of interfaces, but it does work...but for some reason the new images from download won't boot properly even after an apt update && apt upgrade then set armbian-install to USB.

Not sure if the script in newer issues have problems or what

 

/home/warhawk# lsblk -s
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda1        8:1    0 931.5G  0 part
└─sda       8:0    0 931.5G  0 disk
sdb1        8:17   1  57.6G  0 part
└─sdb       8:16   1  57.6G  0 disk
mmcblk0p1 179:1    0  14.7G  0 part /var/log.hdd
│                                   /
└─mmcblk0 179:0    0  14.8G  0 disk
zram0     254:0    0 499.5M  0 disk [SWAP]
zram1     254:1    0    50M  0 disk /var/log
zram2     254:2    0     0B  0 disk

 

/home/warhawk# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=436596k,nr_inodes=109149,mod                                                                                                                                                             e=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmod                                                                                                                                                             e=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102300k,mode=755)
/dev/mmcblk0p1 on / type ext4 (rw,noatime,errors=remount-ro,commit=600)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relat                                                                                                                                                             ime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelega                                                                                                                                                             te,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=29,pgrp=1,time                                                                                                                                                             out=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatim                                                                                                                                                             e)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,no                                                                                                                                                             exec,relatime,mode=700)
tmpfs on /tmp type tmpfs (rw,nosuid,relatime)
/dev/mmcblk0p1 on /var/log.hdd type ext4 (rw,noatime,errors=remount-ro,commit=60                                                                                                                                                             0)
/dev/zram1 on /var/log type ext4 (rw,relatime,discard)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relati                                                                                                                                                             me)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=102296k,nr_ino                                                                                                                                                             des=25574,mode=700,uid=1000,gid=1000)

 

 

root@orangepipc:/home/warhawk# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 15 Feb 18 13:08 236e9e17-4169-4077-a0d9-2463f4b614ff -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 10 Feb 18 13:08 7e6a8eab-cf51-4649-9526-dd8adfeb63e4 -> ../../sda1
lrwxrwxrwx 1 root root 10 Feb 18 13:08 dfc301cd-0ae2-4cc2-85e6-4b6c9c6de20b -> ../../sdb1
root@orangepipc:/home/warhawk# cat /etc/fstab
UUID=236e9e17-4169-4077-a0d9-2463f4b614ff / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0

 

 

In case of emergency...can I do it manually somewhat by following this howto?  (not sure how to copy root to the USB...or do I copy all of it to the USB?)
https://www.pragmaticlinux.com/2020/08/move-the-raspberry-pi-root-file-system-to-a-usb-drive/

 

I guess I could do the rsync (thing of the page) of the / to the SD, then ensure the armbianEnv.txt shows the boot partition as the USB at dfc301cd-0ae2-4cc2-85e6-4b6c9c6de20b correct, well and edit /etc/fstab as well

 

Edited by WarHawk_AVG
Posted

Hello @all,

 

I'm experiencing the same problem, no boot after copying to the USB drive. I've tested it with two different OrangePiPC's, also with two different USB Harddisks, one is a magnetic harddisc, the other a brandnew SSD.

 

Any help is appreciated..

 

Thanks

Armin

Posted (edited)

well crap...

https://docs.armbian.com/User-Guide_Recovery/#flashing-boot-loader

 

Quote

U-Boot Shell Access¶

If you broke the system you can try to get in this way. You have to get to u-boot command prompt, using either a serial adapter or monitor and usb keyboard.

Note: USB support in u-boot is currently not enabled on all H3 boards.

After switching power on or rebooting, when u-boot loads up, press some key on the keyboard (or send some key presses via terminal) to abort default boot sequence and get to the command prompt:


Is there no way to just copy the /boot partition to the SD card, then the root partition only on the USB?
Would make it SOOOO much easier to have a small 256mb /boot partition (that could live forever and practically untouched unless booting on the SD card), then the rest under the linux format...

 

reflashing...again

This might help...maybe (would love to be able to move the rootfs to a USB and just boot up from the SD)
https://paste.armbian.com/avocuvopid

 

Right now the /dev/sdb1 formatted as BTRFS has the entire "before the hang" rootfs on the drive...I wonder if I could just update the /boot/armbianEnv.txt (from the new working only from the SD card reflash)
 

verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
rootdev=UUID=705b28eb-7ba5-481e-ac44-cb93d2cfd612
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

to

verbosity=1
bootlogo=false
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
rootdev=UUID=b8a31eff-ba94-410f-9568-53171f393e3b
rootfstype=btrfs
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

from

Command (m for help): Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): Partition number (1-4, default 1): First sector (2048-31116287, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (8192-31116287, default 31116287): NAME        FSTYPE   SIZE MOUNTPOINT UUID
sda                931.5G            
└─sda1      ext4   931.5G            7e6a8eab-cf51-4649-9526-dd8adfeb63e4
sdb                 57.6G            
└─sdb1      btrfs   57.6G            b8a31eff-ba94-410f-9568-53171f393e3b
mmcblk0             14.8G            
└─mmcblk0p1 ext4     1.9G /          705b28eb-7ba5-481e-ac44-cb93d2cfd612
zram1                 50M /var/log   
zram2                  0B  


Once the crash happened. The data is moved(rsync from the install command) and is still there in the locked USB drive...it should be able to just point there...or is that H3 disable from the above post mean it will NEVER work?
It worked before on an older release....

I guess worse comes to worse...I would just have to reflash for the bazillionth time...

Edited by WarHawk_AVG
Posted

Found a spare card...flashed...working like a boss off the SD...was just wishing there was a way to have a boot SD that pointed to a USB/HDD for the OS

will u-boot work on a fat32SD card like raspbian?  If only there was a 2nd partition...

Posted (edited)

I believe I figured out why it's not working

The proper format for /etc/fstab would be
UUID=${target_partition_uuid} / ext4 defaults,noatime 0 1

Rather than
/dev/disk/by-uuid/${target_partition_uuid} / ext4 defaults,noatime 0 1

Might be a quick fix in the script...and/or have people change that entry...for some reason it hangs on reboot because it cant' seem to get back the /dev/disk deal

Also, found that the script was not commenting out the /dev/mmcblk0p2 above the entry it placed

Just like in the adafruit script...it's putting the wrong ID in /etc/fstab so upon booting it can't figure out the /dev/disk/by-uuid/ entry rather than just the UUID=

Can someone verify??
Ah heck...what can I loose other than a new reflashing huh?

 

 

Edited by WarHawk_AVG
Posted

I never got a chance to try a self build image...however

After updating I decided to give it a whirl...I have a 1TB USB->SSD adapter (yeah, way overkill!!!!), and a 64GB USB drive...
The 1TB drive has a 1/2 dozen docker containers running on em (the OPiPC isn't a powerhouse by any stretch...but by golly it's running...and has been running like a BOSS!!!!  Thanks Armbian devs!)

Gave it a whirl one last time...even did it remotely! (was worried I would bork it and get locked out...but it came right up!)

warhawk@orangepipc:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 931.5G  0 disk 
└─sda1        8:1    0 931.5G  0 part /home/warhawk/hdd
sdb           8:16   1  57.6G  0 disk 
└─sdb1        8:17   1  57.6G  0 part /var/log.hdd
                                      /
mmcblk0     179:0    0  14.8G  0 disk 
└─mmcblk0p1 179:1    0  14.7G  0 part /boot
                                      /media/mmcboot
zram0       254:0    0   499M  0 disk [SWAP]
zram1       254:1    0    50M  0 disk /var/log
zram2       254:2    0     0B  0 disk

[Yeah, I have log2ram and zram-tools installed so it shows the mount point as /var/log.hdd and /]

Worked like a boss...it did however blow out the /etc/fstab entry mounting the /dev/sda1 to /home/warhawk/hdd link...but was a VERY easy fix!

warhawk@orangepipc:~$ cat /etc/fstab
# <file system>                    <mount point>    <type>    <options>                            <dump>    <pass>
tmpfs                        /tmp        tmpfs    defaults,nosuid                            0    0
UUID=705b28eb-7ba5-481e-ac44-cb93d2cfd612    /media/mmcboot    ext4    defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide    0    1
/media/mmcboot/boot                  /boot        none    bind                                0       0
UUID=3c82ef17-f148-4cd5-afb5-efa861ad05ef    /        btrfs    defaults,noatime,commit=600,compress=lzo,x-gvfs-hide        0    2
UUID=7e6a8eab-cf51-4649-9526-dd8adfeb63e4    /home/warhawk/hdd    ext4    defaults,noatime,commit=600,x-gvfs-hine            0    0




I even found an older version of geekbench built for older ARM and ran it...nope..not a power house
https://browser.geekbench.com/v5/cpu/compare/21830053?baseline=21830053

Even got an ARMv7 version of netdata working in a docker and even though it is a wee bit heavy on system resources, it's running it

Odd thing is...the OPiPC has been more resilient than my daggum RPi4B 8GB...for some reason it either locks up or burns out the stupid POE hats I put on it...but the OPiPC keeps chugging!

 

Kudo's to you and the dev team!  OUTSTANDING job!!!!!!!!

 

N_A - Geekbench.pdf

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines