Fresh RPI3 image + update => error upgrading openmediavault then unusable

I was able to reproduce. dpkg.log here.

@ryecoaaron: Might be an idea to switch over from Raspbian to a clean armhf Debian as base? At the same time leaving old ARMv6 userland behind and switch to ARMv7?

Might be worth a test to replace the whole userland on the ext4 partition except /boot and /lib/modules (4.4.* stuff removed) with the one from my most recent images (Clearfolg) and then

• rm /etc/apt/sources.list.d/armbian.list
• echo "raspberrypi" >/etc/hostname
• echo -e "snd-bcm2835\nipv6\nr8152\nax88179_178a" >/etc/modules
• Some slight modifications below /etc/update-motd to do an Armbian unbranding

If a test is successful and you figure out which repo to add to just get rpi kernel/firmware upgrades but no Raspbian userland stuff I can generate a fresh OMV/Armbian image for you with these fixes applied. But I won't assemble this userland with the FAT32 stuff on the /boot partition.

Zitat von ryecoaaron

I'll give it a shot but I am going to be on vacation for the next four days with little or no internet.

I assembled something from your latest image and the Clearfog rootfs. At least it works almost like a charme: http://sprunge.us/PTSC

But adding to the above measures it's also important to overwrite /etc/fstab in the end with the defaults:

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1

'apt upgrade' worked flawlessly.

Zitat von scuub

I look forward to your work.

There you go: Building OMV automatically for a bunch of different ARM dev boards

Feedback welcomed!

Zitat von scuub

everything works perfectly, the boot-up time was not as bad as you said, roughly 5 minutes on sd card.

This depends more or less on the SD card used. The most important factor is high random IO write performance and that's why I only use SanDisk Extreme Pro or even Plus (yeah, the 'twice the price' variant) or if endurance isn't top priority then Samsung EVO+ with either 32GB or 64GB (the larger the longer until they wear out): https://forum.armbian.com/inde…/954-sd-card-performance/

BTW: Final RPi 2/3 image released few hours ago. I would believe @ryecoaaron will upload this on Sourceforge after some testing...

Zitat von ryecoaaron

Done.

Thanks a bunch. Please replace readme.txt there with an updated version outlining some important stuff: https://pastebin.com/raw/yvC7GWGh

Zitat von scuub

Errors were encountered while processing:
openmediavault
openmediavault-omvextrasorg
openmediavault-resetperms

Same problem for me with a fresh RPi 2 install with omv_rpi2_rpi3_3.0.63.img
No problem with updating everything else.
When trying to update those 3 packages, the webgui login window always disappear, only the blue OMV backgroung is here, the only way to get it working again is restoring the .img on the sdcard :'((

Sad 1st try on OMV for me :s

Zitat von petrus

Same problem for me with a fresh RPi 2 install with omv_rpi2_rpi3_3.0.63.img

This whole thread is about obviously this specific older OMV image running in dependency problems NOW since based on Raspbian. We spent some hours to rebase OMV on a true Debian userland which is available now as OMV_3_0_79_RaspberryPi_2_3_4.9.35.7z which is confirmed to work (at least no dependency hassles, see above!)

So why don't you follow these steps: https://forum.openmediavault.org/index.php/Thread/18991 (test your SD card first, use Etcher to burn the image, be somewhat patient since this new image needs up to 15 minutes on 1st boot to finish installation with network cable connected and then reboots once), try it again and report back here?

@ryecoaaron: On https://sourceforge.net/projec…/Raspberry%20Pi%20images/ the older images are still available. Maybe hiding/removing them to save users from running into this issue again and avoiding confusion?

Zitat von tkaiser

This whole thread is about obviously this specific older OMV image running in dependency problems NOW since based on Raspbian. We spent some hours to rebase OMV on a true Debian userland which is available now as OMV_3_0_79_RaspberryPi_2_3_4.9.35.7z which is confirmed to work (at least no dependency hassles, see above!

Many thx for your hard work !
Sry I'm new here, I was not very sure about this source... So if it's validated by the whole OMV team, I'll download and use it with pleasure

Zitat von tkaiser

@ryecoaaron: On https://sourceforge.net/projec…/Raspberry%20Pi%20images/ the older images are still available. Maybe hiding/removing them to save users from running into this issue again and avoiding confusion?

Good idea !
People like me will come for 1st time on the Doc/download pages... as I've done some days ago.
1st experience with OMV will be better if it's working after plugging the power cable

Thx all for your work, I'll try this new .img ASAP

I was thinking about "lesson 1 : security"... nothing more I think not being alone to prefer installing softwares from a "good" people...

Zitat von petrus

I was thinking about "lesson 1 : security"... nothing more I think not being alone to prefer installing softwares from a "good" people...

That's the reason why I'm contributing to Armbian (which is the base of this image). Since with Armbian's build system https://github.com/armbian/build I can generate fully automated Debian or Ubuntu OS images for +50 SBC from scratch. So no need to trust in anyone who provided an image that there are no backdoors and so on.

Unfortunately with this RPi image this is slightly different. It was not booted already, still the userland has been created from scratch by scripts (assembling the image from upstream Debian sources) but at least I have fiddled manually around to improve stuff for Raspberries. And yes, you've to trust me that I didn't added something evil but I would be an idiot if I did so (since one of the main reasons to work on Armbian are security concerns).

But as far as I know SBC OS images 'where someone manually fiddled around' whom you have to trust are what you get almost everwhere (except of the *BSDs and Armbian where you can set up a virtual machine, audit the build scripts and then let a genuine OS image be created from scratch -- just not for Raspberries since Armbian don't support them for various reasons).

BTW: My main security concern with all those new Armbian based OMV images is that there's no password policy forcing users to immediately change root and GUI passwords (which is something Armbian usually does but since I contribute here to a different projekt I chose to remain compatible to established rules here)

Zitat von ryecoaaron

Obviously, forcing the password change in the web interface for the admin user makes sense. But, where should the root password be changed?

IMO it should be changed at the same time the user chooses a new password in the web interface (allowing the user to change later the root password via CLI without adjusting the web interface password as well, but this is something a dialog should tell).

BTW: I've also some other 'security' concerns. In these OMV images the deb sources are already referenced as https links instead of http as all tutorials show. But then

• https://github.com/armbian/bui…ize-image.sh.template#L92 (would be better to be able to use HTTPS?)
• https://github.com/armbian/bui…ize-image.sh.template#L68 (why '--allow-unauthenticated'?)

Would be nice to switch to TLS/HTTPS for all transport methods and use also gpg signature checks.