Raspberry pi 4 announced, better than 3?

Zitat von ryecoaaron

Please remember you are using a beta version of OMV where most of the omv-extras are not ready on a brand new board...

No worry. I dont use any extra atm in my RPI 3. No teamviewer, docker, transmission, or extra.
Im only using Samba to copy and read files from a 24/7 Rpi3 Nas

I was waiting for a Rpi4 with Gigabit ethernet and usb 3.0 to upgrade my read/write speeds from 20 mb/sec to at least, 100 mb/sec

I want to know how to install OMV 5 in RPI 4 , The only version I see in the website is for amd64....... so, I need a guide. XD

Thanks a lot Ryecoaaron

Hi ,

I installed the OMV in Raspberry Pi 4 Model B
This version (https://sourceforge.net/projec…/Raspberry%20Pi%20images/)

But not working ? Please help

For those that have ordered the RPi4 already, what are you planning on doing with them e.g. are you going to be adding multiple hard drives?

I am extremely tempted to get one (just because they are cool) but cannot quite see what there main advantages are, when it comes to NAS use.

Zitat von elsmandino

For those that have ordered the RPi4 already, what are you planning on doing with them e.g. are you going to be adding multiple hard drives?

I am extremely tempted to get one (just because they are cool) but cannot quite see what there main advantages are, when it comes to NAS use.

I only need one drive so..... Enough for file server NAS for home (Movies, Music, etc).

For Backup , I think you can use multiple powered hard-drive attached to each usb of RPI4, or using a powered Usb3.0 hub......

Meanwhile, Let OMV-team enough time for release omv 5.0

That is my slight issue - I also have a single hard drive for my home server.

I am currently using an Odroid HC2, which has the advantage of a neat little case and a single power supply.

When you add up all the cost of everything, I am not sure the Pi route is going to be the cheaper option either.

Next try to fight silent bit rot. A btrfs raid1 made out of two USB3 attached SSDs:

root@rpi4:/# btrfs fi df /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0
Data, RAID1: total=2.00GiB, used=776.00KiB
System, RAID1: total=8.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B


root@rpi4:/# btrfs fi show /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0
Label: none  uuid: 47df1208-fd9c-4ab2-884f-bec63637b73a
	Total devices 2 FS bytes used 904.00KiB
	devid    1 size 476.94GiB used 3.01GiB path /dev/sda
	devid    2 size 119.24GiB used 3.01GiB path /dev/sdb


root@rpi4:/# grep ADplus_SuperVer_DB12345678969 /etc/mtab 
/dev/sda /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0 btrfs rw,relatime,compress=lzo,space_cache,subvolid=5,subvol=/ 0 0

I hope that with release of OMV5 the mount options are adjusted to noatime,nodiratime instead of relatime.

Debug output: http://ix.io/1MRH

Please be aware that you can run into ugly underpowering issues that look like 'UAS driver' issues or 'btrfs is not ready yet' BS: https://www.cnx-software.com/2…ni-review/#comment-564128

Underpowering might be related to exceeding the current limitations on the RPi 4 USB ports (close to 1.2A max for all 4 USB ports combined) or it's the usual undervoltage sh*t show we know from almost all (5V powered) SBC already. For anyone thinking about the RPi 4 don't forget to buy their own USB-C PSU!

Zitat von tkaiser

OMV5 installation routine the armbian-config way has some bugs that need to be fixed

My fixes are online now.

To get a BETA OMV5 install on the RPi 4 all I did now was:

• Grab Raspbian Buster Lite and burned it with balenaEtcher
• Created an empty file called ssh on the boot partition of the SD card
• Inserted SD card and booted the RPi 4
• after one minute ssh pi@raspberry.local from my laptop (default password is 'raspberry')
• sudo -s
• echo "deb [arch=arm64] http://apt.armbian.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/armbian.list
• apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 9F0E78D5
• apt update
• apt install armbian-config
• armbian-config (Software --> Softy --> Install OMV)
• apt upgrade
• reboot

Et voilà:

If you access the OMV UI the first time do the following things first:

• In 'General settings' change the admin password
• In 'Access Rights Management' under 'Users' change the password of the default pi user and add the ssh group (this will allow to remotely administrate OMV through SSH and to use this account for authentication. Windows users look here)
• optionally create new user accounts and optionally assign these to the groups ssh and sudo in case those users should also administrate the system remotely
• optionally change the hostname to something like rpi4. This allows you to access all OMV services via this name (no need to remember boring IP addresses). Otherwise the OMV install will be available as http://raspberrypi or http://raspberrypi.local
• If you change the hostname you need to define the eth0 interface in Network --> Interfaces (set it to DHCP unless you really really know what you're doing. To get a static IP address for whatever reasons assign a static DHCP lease at your router)

Zitat von tkaiser

A btrfs raid1 made out of two USB3 attached SSDs

Continuing with this btrfs raid1 connected to the two USB3 ports of the RPi 4. This test is about reliability and testing for correct write barrier semantics.

As almost everybody in the storage world knows btrfs with recent kernels is rock solid wrt power losses or crashes since it's designed for this (CoW -- copy on write). But this only works if the whole data path to the drives in question implements write barriers correctly. So let's test this on RPi 4 since here the XHCI controller is entirely new and the USB implementation of all the older RPi variants is known to be quirky.

I used the btrfs raid1 to ensure maximum drive activity when testing with iozone -e -I -a -s 1000M -r 1024k -i 0 -i 1 -i 2 (I tested also with other record sizes down to 1K to maximize stress on the storage). Then while the write test is running I simply unplugged the power cable to simulate a power loss.

This has been repeated 10 times, always checking dmesg output for traces of problems followed by a btrfs scrub:

root@rpi4:/# dmesg | grep -i btrfs
[    7.936253] Btrfs loaded, crc32c=crc32c-generic
[    7.937862] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 116 /dev/sda
[    8.168583] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 116 /dev/sdb
[    8.640809] BTRFS info (device sda): use lzo compression, level 0
[    8.640824] BTRFS info (device sda): disk space caching is enabled
[    8.640836] BTRFS info (device sda): has skinny extents
[    8.716824] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    7.694596] Btrfs loaded, crc32c=crc32c-generic
[    7.696193] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 118 /dev/sda
[    7.934070] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 118 /dev/sdb
[    8.427242] BTRFS info (device sda): use lzo compression, level 0
[    8.427257] BTRFS info (device sda): disk space caching is enabled
[    8.427270] BTRFS info (device sda): has skinny extents
[    8.562643] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    7.826036] Btrfs loaded, crc32c=crc32c-generic
[    7.827652] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 120 /dev/sda
[    8.013274] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 120 /dev/sdb
[    8.520735] BTRFS info (device sda): use lzo compression, level 0
[    8.520750] BTRFS info (device sda): disk space caching is enabled
[    8.520763] BTRFS info (device sda): has skinny extents
[    8.892342] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    7.813055] Btrfs loaded, crc32c=crc32c-generic
[    7.814934] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 122 /dev/sda
[    7.908326] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 122 /dev/sdb
[    8.396830] BTRFS info (device sda): use lzo compression, level 0
[    8.396845] BTRFS info (device sda): disk space caching is enabled
[    8.396857] BTRFS info (device sda): has skinny extents
[    8.895063] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    7.795318] Btrfs loaded, crc32c=crc32c-generic
[    7.798294] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 125 /dev/sda
[    8.004393] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 125 /dev/sdb
[    8.494352] BTRFS info (device sda): use lzo compression, level 0
[    8.494367] BTRFS info (device sda): disk space caching is enabled
[    8.494380] BTRFS info (device sda): has skinny extents


root@rpi4:/# dmesg | grep -i btrfs
[    7.765093] Btrfs loaded, crc32c=crc32c-generic
[    7.766695] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 125 /dev/sda
[    7.838069] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 125 /dev/sdb
[    8.309263] BTRFS info (device sda): use lzo compression, level 0
[    8.309278] BTRFS info (device sda): disk space caching is enabled
[    8.309290] BTRFS info (device sda): has skinny extents
[    8.888434] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    7.871459] Btrfs loaded, crc32c=crc32c-generic
[    7.873151] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 128 /dev/sda
[    7.959231] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 128 /dev/sdb
[    8.451649] BTRFS info (device sda): use lzo compression, level 0
[    8.451664] BTRFS info (device sda): disk space caching is enabled
[    8.451677] BTRFS info (device sda): has skinny extents
[    8.623454] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    8.038993] Btrfs loaded, crc32c=crc32c-generic
[    8.042321] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 130 /dev/sda
[    8.243179] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 130 /dev/sdb
[    8.730296] BTRFS info (device sda): use lzo compression, level 0
[    8.730311] BTRFS info (device sda): disk space caching is enabled
[    8.730324] BTRFS info (device sda): has skinny extents
[    9.215865] BTRFS info (device sda): checking UUID tree


root@rpi4:/# dmesg | grep -i btrfs
[    7.733941] Btrfs loaded, crc32c=crc32c-generic
[    7.735547] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 133 /dev/sda
[    7.806518] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 133 /dev/sdb
[    8.308454] BTRFS info (device sda): use lzo compression, level 0
[    8.308470] BTRFS info (device sda): disk space caching is enabled
[    8.308483] BTRFS info (device sda): has skinny extents


root@rpi4:/# dmesg | grep -i btrfs
[    7.891269] Btrfs loaded, crc32c=crc32c-generic
[    7.892890] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 1 transid 133 /dev/sda
[    7.991365] BTRFS: device fsid 47df1208-fd9c-4ab2-884f-bec63637b73a devid 2 transid 133 /dev/sdb
[    8.466066] BTRFS info (device sda): use lzo compression, level 0
[    8.466081] BTRFS info (device sda): disk space caching is enabled
[    8.466094] BTRFS info (device sda): has skinny extents
[    8.599848] BTRFS info (device sda): checking UUID tree


root@rpi4:/# btrfs scrub start /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0
scrub started on /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0, fsid 47df1208-fd9c-4ab2-884f-bec63637b73a (pid=1670)


root@rpi4:/# btrfs scrub status /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0
scrub status for 47df1208-fd9c-4ab2-884f-bec63637b73a
	scrub started at Thu Jun 27 13:40:18 2019 and finished after 00:00:14
	total bytes scrubbed: 5.53GiB with 0 errors


root@rpi4:/# /home/pi/rock64_diagnostics.sh -u
Generating diagnostic logs... 


IP obfuscated log uploaded to http://ix.io/1MUx
Please post the above URL on the forum where you've been asked for it.
root@rpi4:/# 


root@rpi4:/# cd /srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0/omv/


root@rpi4:/srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0/omv# iozone -e -I -a -s 1000M -r 16384k -i 0 -i 1 -i 2
	Iozone: Performance Test of File I/O
	        Version $Revision: 3.487 $
		Compiled for 32 bit mode.
		Build: linux-arm 


	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa,
	             Alexey Skidanov, Sudhir Kumar.


	Run began: Thu Jun 27 13:54:19 2019


	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 1024000 kB
	Record Size 16384 kB
	Command line used: iozone -e -I -a -s 1000M -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         1024000   16384   135158   134265   356990   356133   354697   133370                                                                


iozone test complete.
root@rpi4:/srv/dev-disk-by-id-usb-ADplus_SuperVer_DB123456789699-0-0/omv#

No problems whatsoever and as such a confirmation that the USB3 controller on the RPi 4 does not suck unlike the implementation on the older RPi.

Unfortunately still some retired forum members spend a lot of their spare time on spreading BS and FUD in this forum as well as polluting related Github issues. While it's perfectly understandable that users lack knowledge and testing methodology the inability to grasp even basics and actively refusing to learn sucks and results in sabotaging the work done here. I'm sick of this and won't continue until this problem is resolved.

Zitat von tkaiser

My fixes are online now.
To get a BETA OMV5 install on the RPi 4 all I did now was:

• Grab Raspbian Buster Lite and burned it with balenaEtcher
• Created an empty file called ssh on the boot partition of the SD card
• Inserted SD card and booted the RPi 4
• after one minute ssh pi@raspberry.local from my laptop (default password is 'raspberry')
• sudo -s
• echo "deb [arch=arm64] http://apt.armbian.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/armbian.list
• apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 9F0E78D5
• apt update
• apt install armbian-config
• armbian-config (Software --> Softy --> Install OMV)
• apt upgrade
• reboot

Et voilà:

If you access the OMV UI the first time do the following things first:

• In 'General settings' change the admin password
• In 'Access Rights Management' under 'Users' change the password of the default pi user and add the ssh group (this will allow to remotely administrate OMV through SSH and to use this account for authentication. Windows users look here)
• optionally create new user accounts and optionally assign these to the groups ssh and sudo in case those users should also administrate the system remotely
• optionally change the hostname to something like rpi4. This allows you to access all OMV services via this name (no need to remember boring IP addresses). Otherwise the OMV install will be available as http://raspberrypi or http://raspberrypi.local
• If you change the hostname you need to define the eth0 interface in Network --> Interfaces (set it to DHCP unless you really really know what you're doing. To get a static IP address for whatever reasons assign a static DHCP lease at your router)

Help

Zitat von serkan190

Help

You're typing stuff in a Terminal (and missed the leading / in front of /etc/apt/sources.list.d/armbian.list). This is not going to work. Better use SSH as hinted to above. Just use your normal computer and do ssh pi@raspberry.local to connect to the RPi (works on every OS except older Windows versions than Win10, there you need Putty or something like that, in Win10 you need to open cmd.exe).

With SSH you can use copy&paste then...

If you didn't created the empty file called ssh on the boot partition you need to follow these procedures: https://www.raspberrypi.org/documentation/remote-access/ssh/

Here is a nice synopsis of the RPI4.

The Raspberry Pi 4's Most Interesting Quirks

Mainly:
1) It runs even hotter
2) It uses more power
3) You can't play 4k video on it.
4) The processor is much faster
5) Ethernet is finally fast
6) It has USB 3

See the article for fancy graphs.

Zitat von tkaiser

You're typing stuff in a Terminal (and missed the leading / in front of /etc/apt/sources.list.d/armbian.list). This is not going to work. Better use SSH as hinted to above. Just use your normal computer and do ssh pi@raspberry.local to connect to the RPi (works on every OS except older Windows versions than Win10, there you need Putty or something like that, in Win10 you need to open cmd.exe).
With SSH you can use copy&paste then...

If you didn't created the empty file called ssh on the boot partition you need to follow these procedures: https://www.raspberrypi.org/documentation/remote-access/ssh/

Tank you problem fixing , Omv 5 work but harddisk sharing does not work properly

I'll try re-installation later

Zitat von ryecoaaron

Try the OMV 4 image then - New approach for Raspberry Pi OMV images

This image not working.

tkaiser I managed to run it with the method your friend told me ,

Zitat von serkan190

Tank you problem fixing , Omv 5 work but harddisk sharing does not work properly
I'll try re-installation later

I've re-installed it now and the harddisk works fine Maximum speed data transfer

missing List

Root password
mini Dlna plugin
transmission plugin
---------------------------------------------------------
@Edit: system crashed after rebooting
---------------------------------------------------------
@Edit2 : Reinstall with (Raspbian Buster with desktop) Not lite version

Works greate,
no system crash at this time,

Reinstall with (Raspbian Buster with desktop) Not lite version

Works greate,
no system crash at this time,

File transfer speed 115 MB/s
CPU load during transfer %40
Hdd WD my passport 1TB

Zitat von tkaiser