By the way I think I solved the issue leaving the second disk in a partionless state, other thing is creating /boot outside of the btrfs filesystem; I did the same on my real hardware (WOW!!! ) and it worked.

Soon my recommendations or at least what I did... :-P

I re-did the installation and this time the issue doesn't happen, perhaps because I did all my steps clearly and in the right sequence, and now I have Devuan on a Btrfs RAID using subvolumes as partitions:

gnuser@devuan:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Devuan GNU/Linux 3 (beowulf)
Release:	3
Codename:	beowulf

gnuser@devuan:~$ mount | grep btrfs
/dev/sdb1 on / type btrfs (rw,noatime,discard,space_cache,autodefrag,subvolid=268,subvol=/@)
/dev/sdb1 on /home type btrfs (rw,noatime,discard,space_cache,autodefrag,subvolid=270,subvol=/@home)
/dev/sda3 on /media/snapshots type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)

gnuser@devuan:~$ sudo btrfs fi df /
Data, RAID0: total=4.00GiB, used=3.64GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=256.00MiB, used=125.92MiB
GlobalReserve, single: total=16.00MiB, used=0.00B
gnuser@devuan:~$ sudo btrfs fi show
Label: 'btraid'  uuid: cf6cf3c5-f308-46b8-b4e8-dea7ad870436
	Total devices 2 FS bytes used 3.76GiB
	devid    1 size 16.00GiB used 2.28GiB path /dev/sdb1
	devid    2 size 16.00GiB used 2.28GiB path /dev/sdc

Label: 'snapshots'  uuid: bcbe0d7f-14c9-4ad4-86c4-27362d64ef93
	Total devices 1 FS bytes used 3.66GiB
	devid    1 size 5.59GiB used 4.51GiB path /dev/sda3

gnuser@devuan:~$ lsblk 
NAME             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                8:0    0   16G  0 disk  
├─sda1             8:1    0  524M  0 part  /boot/efi
├─sda2             8:2    0  525M  0 part  /boot
├─sda3             8:3    0  5.6G  0 part  /media/snapshots
└─sda4             8:4    0  9.4G  0 part  
  └─sda4_crypt   254:0    0  9.4G  0 crypt 
    ├─vgcr0-swap 254:1    0  3.7G  0 lvm   [SWAP]
    └─vgcr0-enc  254:2    0  5.7G  0 lvm   /mnt/private
sdb                8:16   0   16G  0 disk  
└─sdb1             8:17   0   16G  0 part  /home
sdc                8:32   0   16G  0 disk  
sr0               11:0    1 1024M  0 rom   

I am almost ready to install Devuan on a real hardware!!!

Yes of course, I also installed the Guest Addition but no traces of vboxdrv, and vboxsf and vboxvideo exist as modules but won't load even if I put in /etc/modules/modules.conf.

On the same HOST I have also Debian testing which works perfectly with all these features available...

Thanks for all these information, but I have been using Debian testing as a rolling distro so far, and I feel comfortable with it, you probably said me the same on the Debian forum... :-p

Epic fail...

I must dig into it... But I found the Refract Installer quite convoluted I hope this will be more user friendly.

I am ok with unexpected breakage, the amount of issues with Debian testing are really few compared with Debian Sid, I am also thinking to use BTRFS to handle issues with the updating and eventually revert to the previous status.

I am still figuring out the best option, but one thing is sure I don't like systemd as much as I don't like stable release distro.

This exactly what I am trying to do... Testing/Ceres... Just Unstable is too extreme for me, I had a lot of headaches with Debian Sid unless Devuan, since is delayed respect Debian, doesn't have the same issues and get all packages already fixed from upstream.

It is "safer" using Ceres compared "theoretically" with Sid?

Thanks for video screencast I missed that option, I have been always creating the encryption through the menu on top. Honestly I am pretty new to encryption I started using on POP and I used this method:

https://write.snopyta.org/gnuserland/tu … encryption

Now I am doing some test with the refracta installer but it I find it a little bit convoluted for my tastes...

I used to do my partitions manually once, when I had plenty of time available, then I decided that a smart installer is wise and smart thing and I like very much using it, more is complete the better. And the Debian installer is really good, beside the fact that works on several platform can perform LVM and encryption; others derivatives like Ubuntu Desktop, Mint, POP!_OS, Elementary or Linux MX cannot handle installation on multiple disks. The only exception is the Ubuntu server installer.

Other distros like gentoo, also arch, are better designed to be handled manually. Recently I discovered KISS which follow the same approach, I'd like to play with it but I don't think will ever have time...

Thanks...

Debian and sysvinit has been working well for a long time but moving forward is a good thing when all the parts work together in harmony. Systemd is good for what it achieves, but is really awful for everything else. Systemd is also the biggest error of Debian, but Debian is under pressure by Google, Canonical, probably also IBM Hat.

Check how Canonical predates the Debian work, it is also true that now many Canonical devs are also Debian devs, them were probably recruited from Canonical which would be good if that would not have harmed Debian...

http://forums.debian.net/viewtopic.php? … 72#p687205

I find Gimp 2.10, better under any aspects...

I am pretty new here but I'd like to share my point of view since I have been watching this situation from the very first time Poettering made his first fart about systemd...

Init free/freedom is cool but it is really discouraging when is time to speak in terms of technology. Even being an init agnostic distro doesn't make really sense, it generates the paradox that if I would use Devuan with systemd it would be the same as installing Debian.

That brings to my point, Devuan needs to focus on the init alternatives to systemd and therefore must do a shift into his communication; practically speaking is something really close to a marketing or a strategic plan.

The main approach is surpassing sys-v must supporting, for the moment, OpenRC as default init. I see this latter as the key to state Devuan like the most easy, secure and stable Linux distro available. As a matter of fact Gentoo, because its design, is one of the most secure Linux distro enterprise oriented and it relies on OpenRC as default init, and this makes sense, with over a million lines of code would you entrust your critical mission to systemd?

Not for sure, this is the crack where you can throw Devuan as a spear and break the wall, shaking the Linux establishment and also putting a bit of scare upon someone...

However all this question of systemd, in my dumb opinion, it is has been addressing in a perspective that belongs more to the end users rather than the sys-admins. Systemd solves and addresses a lot of issues difficult to handle with just shell scripts, if it wasn't defective by design we would be not here speaking about it.

This is the part of whole situation where I see a contradiction and hence the weakest point of Devuan. Devuan is born by an initiative of Admins annoyed, in my opinion, by the methods around systemd: lack of participation, lack of discussion, lack of inclusion, etc... Rather than for the application itself which is pretty neat on the surface. But Devuan is not resolving the issues that systemd stated to resolve while it resolves aspects that belong mainly to the end users neeed like freedom, security, minimalism. As a matter of fact you can see that Devuan has generated a considerable amount of desktop distros but very few server distros. Therefore something got wrong somewhere in the communication.

It is clear that Devuan should move away from sysv and the freedom init per se, those must be preserved as inner value though. But when you leaves the political and philosophical topics eventually you have the technology topic and sys-v is not a good argument today.

Next move would be embracing the security topic more rigorously. OpenRC goes in the right direction, S6 goes even better. The latter is also seems very suitable for admins and many end users use cases. A fortunate win-win combination.

The main reason to avoid systemd is security, init freedom may been the impulse but it is time to reorganize the communication and the priorities around a clear statement. This would encourage people to join Devuan for a precise scope rather for something too much philosophical or political. There are a lot of people involved in Linux just for work that don't see and don't understand all this fuss around the init debate, they are probably very few interested in the four freedoms and most likely are Mac or Win user and any distro with systemd solve their daily workload. But what would happen if you start to state all the Linux distro are safe but Devuan is safer because don't use systemd? A rational choice made around rational and proven design flaws in the systemd architecture. At this point you can repeat the systemd mantra and the usual stereotypes like: "it's just work" or 'it makes your work done' etc; but once you raise up the concern, even from a remote security stand point, contemporaneously you create the need for an alternative that must be safest and an interest toward Devuan if you fully understand how to fit that spot.

Devuan guys proved to all the world to be able to create an infrastructure and make this project resilient and so versatile to be used as derivatives' base for many distributions that embrace the same philosophy. Following the pivot of the security just reinforces the need to an alternative init to sys-v and systemd, and hardening Devuan should be one the top priority, in comparison Devuan can be for Linux what OpenBSD is for BSD, an OS geared around security.

I think this is the right path for Devuan because defines clearly the next steps to follow, and justify rationally what has been so far.

Just watch as easier and clear is the OpenBSD description:

Against:

And what happens if you mix both:

This is the shift of communication I was speaking at the beginning. I already wrote too much for a second post, hence I conclude my thread here. Thanks for reading!