Parrot Installer :: the default partition layout


I have a question in regards of the Parrot Security Installer. I really like the idea to avoid swap partition and that we can use encrypted lvm with btrfs file system but I miss one thing. Working with gentoo we always used different partition for system folders so we could maintain better resources access control. How difficult would be to provide as default option an encrypted boot partition and advanced layout with a btrfs subvolumes for /var /home and other mount points of system folders so we could apply permissions to each of in fstab? I know that new grub versions allow to bot from an encrypted boot partition - could we use this in Parrot?

with Kind Regards

You can’t do that with the Debian installer it doesn’t have btrfs volume support as far as I know. I believe you would have to partition it manually first. The closest you could get I’m thinking is a lvm physical volume formatted to btrfs and then further subdivided as you wish. You could of course use standard partitioning and simply break up /var, /home, and /usr, etc. as separate partitions.

I like the idea of:

with encrypted /boot which is available from the download. From this, after installation I am following this:

as a reference guidance and specific for Debian installer changes this:

This is good for my lab because an isolation and flexibility. I do not have to calculate required space and make predictions. The Debian installer looks flexible too so hopefully I can make custom modification for the installation template with a bit of time. If successful I will share findings here,

with Kind Regards

I was thinking about layout like this:

@/var/lib/libvirt/images (option “no copy on write”)
@/var/lib/mariadb (option “no copy on write”)
@/var/lib/mysql (option “no copy on write”)
@/var/lib/pgsql (option “no copy on write”)

but customised for parrot’s specific requirements


btw Could we test it in the next beta release?


This MR adds basic subvolume support. Specifically, it installs the rootfs to the @rootfs subvolume. This is the minimum required to enable future development of the “boot environment” feature. See Bug #941627 and #840248 for more info.