I would like to move my current Ubuntu on zfs root to synex.
It is quite unstable (but that could hardware) and I dislike snap and all my other machines is running debian stable.
I just changed boot manager to zfsbootmenu (so newbie). Is it possible to install sync sharing on the same pool with the installer so having dual boot?
Hi, and welcome — glad to hear you’re considering the move.
Short answer first: no, neither of our installers can install Synex into an existing pool. Both of them create the pool from scratch, so the target disk gets wiped. Let me explain how each one works so it’s clear why.
Desktop edition (Calamares)
The ZFS path in our Calamares setup is fully automatic — there’s no manual partitioning mode for ZFS. It takes the disk you select, writes a fresh GPT table, and lays out an EFI partition, a separate /boot partition formatted as ext4, and one partition for the pool. It then runs zpool create on that partition using the pool name defined in our config (zpsynex), and builds the dataset hierarchy underneath: ROOT/synex/root, ROOT/synex/home, ROOT/synex/var-cache, ROOT/synex/var-log and ROOT/synex/snapshots, each with its own mountpoint and canmount property. There is no import step anywhere in that flow — the pool is always created, never reused.
Server edition (synex-installer)
Same principle, more options. Our TUI installer asks you for the filesystem, then the ZFS topology (single/stripe, mirror, RAIDZ1/2/3) and whether you want native encryption. It creates EFI and boot partitions on every disk destined for the pool, formats the ones on the first disk, and then runs zpool create -R /target against the root partitions according to the topology you picked. It reads the pool name, pool options, dataset options and the dataset list from its config file, and sets the bootfs to zpsynex/ROOT/synex/root. Again, no import of pre-existing pools — zpool create is the only entry point.
About ZFSBootMenu
This is the part that matters most for what you’re trying to do. Both installers keep /boot on a separate ext4 partition, outside the pool, and boot through GRUB. That’s a deliberate design decision: it’s what lets us support ZFS native encryption, since GRUB can’t read an encrypted pool directly. ZFSBootMenu, on the other hand, expects the kernel and initramfs to live inside the dataset in order to treat it as a boot environment. So even if Synex somehow ended up on your existing pool, it wouldn’t show up in your ZBM menu — the layout simply doesn’t match what ZBM looks for.
What I’d suggest
Give Synex its own disk, or its own partition space if you have room, and let the installer create its own pool there. Your Ubuntu pool stays untouched. That much is fully supported today.
Now, here’s the part that probably solves your actual problem: you don’t need to share the pool at all. ZFSBootMenu imports every pool it finds and lists boot environments from all of them, so if Synex sits on its own pool, ZBM will happily show you both systems in the same menu. Separate pools, one boot menu, neither system touching the other.
The only thing standing in the way is our ext4 /boot, and that’s something you can undo after installing. Roughly: move the contents of /boot into the root dataset, drop that partition from fstab, regenerate the initramfs, set bootfs on the pool and org.zfsbootmenu:commandline on the dataset, and drop GRUB out of the picture. Our root dataset already ships with canmount=noauto, which is exactly what ZBM expects, so that part is already in your favour. Worth noting that ZBM carries its own ZFS modules and reads the pool directly, encrypted datasets included — which is precisely why we needed the separate ext4 partition for GRUB and why ZBM doesn’t.
I’ll be honest that this is a post-installation procedure we haven’t documented yet, so you’d be somewhat on your own for the details — but it’s a handful of steps on an already-working system, not a build from scratch. Much less painful than debootstrapping into your existing pool by hand, which was the alternative.
One caveat if you go down this road: if you’re running Secure Boot, ZBM’s EFI binary isn’t signed by Microsoft, so you’d need to sign it with your own key or turn Secure Boot off.
Either way, take a backup with zfs send to an external disk before you start. Better safe than sorry.
This is genuinely useful feedback, by the way — a ZBM-friendly layout is something we’ll look at properly.
Hope that clears things up — happy to go deeper on any of it.
Best regards!
Bruno.