File: 1663608969379330.jpg (248 KB, 1242x1236)

248 KB JPG

fake+gay

>no fagflag contributors
>no coc
im thinking this might be based guys

>>106473118
Imagine needing a bootloader for your shitty, proprietary file system because you can't use EFISTUB

>>106473475
i started using efi yesterday.

tell me more.

>>106473475
You seem confused about what ZFSBootMenu is. It's not a bootloader. It can be used in conjunction with EFISTUB or a bootloader of your choice. It's a utility that allows you to boot kernels off ZFS datasets and lets you manage snapshots. EFI itself cannot read ZFS.

>>106473969
isnt it basically a mini-linux with a micro-userland and interface mimicking a bootloader?

so basically, i got filtered trying to put this on the MBR.
now i changed to EFI and i just put that portable sucker in the EFI/BOOT and it just works.

why isnt UEFI shilled more?

>>106474122
yeah, the portable version is the way to go. no need to fuck around with efibootmgr, just set your BIOS to boot from USB by default and plug it in whenever you want to boot your ZFS roots.

>>106475245
yeah but i put it on an internal partition instead

>>106475245
also, i was referring to the master boot record, when there is no efi to work with, old dos layout drive, so no gpt

>>106475335
i didn't think it worked in legacy bios mode at all, to be honest

>>106475787
well it is a guide on the official site of zfsbootmenu for void linux. basically bootstrapping a linux system and somehow make it work with mbr

>>106473475
>zfs
>proprietary
Technology Enthusiast board btw.

>>106474079
no it's not. it has some basic shell and kinda looks like grub, that's about it.

>>106473969
UEFI is extensible and allows installing file system drivers. There are drivers for most common file systems, including ext*, NTFS, zfs, etc.

>>106476552
And how does that come about, by flashing a custom bios? And I'd have to do that to every motherboard before I can make use of that feature? Why do that when I can stick a FAT32 thing in whatever motherboard I want, that can then boot from any filesystem I want?

>>106476899
That's not how it works, retard. You install the drivers onto the EFI system partition from where they get loaded at boot.

File: sd-boot.png (6 KB, 672x408)

6 KB PNG

>>106473118
NixOS solves this with specialisations and lets you use normal bootloaders (grub, systemd-boot, u-boot etc) instead of having to tinkertranny.

>>106477333
Except that's not the same lmao.

>>106477389
>roll back to any previous system configuration
>boot into customized versions such as different desktop environment like shown in OP's pic
It's even better than zfsbootmenu because instead of needing a tiny separate Linux distro to find your generations, it's all done via lightweight bootloader entries.
What does zfsbootmenu provide that NixOS specialisations don't?
>inb4 data snapshots
Just use normal btrfs/zfs snapshots? You don't need to roll these back at boot since the system configuration, which is what boot rollback is needed for, is handled by NixOS.

>>106477438
You're missing the entire point of ZBM. Spoiler: It's not just for rollbacks.

>>106477495
I'm thinking not in terms of point but in terms of usecase. What usecases does ZBM provide that NixOS specialisations don't? They can both do
>different kernel versions/builds (e.g. LTS or zen or hardened)
>different initramfs
>different userspace configuration (such as desktop environments)
>different filesystem mounts
>rollback and history preserving of all of the above
The only ones I see that NixOS specialisations doesn't do is
>bootstrap a system installation via zfs recv
Fair enough, it's impossible to do with just a bootloader entry approach. But I doubt many people need this.
>boot other distros
Also fair enough. And again I also doubt many people need this.

Bootloaders are such a pain in the dick. Trying to get a linux install going on a USB SSD and woops it installed the bootloader to the internal drive despite me telling it NOT to do that. One reinstall later after unplugging the internal drive, I go to boot the USB drive on a different computer and FUCK YOU it boots into grub rescue mode so I have to figure out what arcane commands will actually get it to run. I miss the BIOS days when it was as simple as putting /boot on the first partition and that was all you needed to do.

>>106477561
Try running a VM and passing through only the USB device and mounting the ISO installer (so the VM has no storage). That's how I did it when I installed Fedora on a USB stick.
And also idk about how other people do it but for me it's still simple, just two partitions on the drive. But instead of /boot I have /efi. The rest is the data partition.

>>106476917
so pretty much exactly what ZFSBootMenu does, then

>>106477630
No, not really.
Loading file system drivers into UEFI makes file systems directly accessible in the EFI shell, you can load additional drivers or EFI executables like boot loaders/kernels, etc.

>>106477587
I make /boot and /boot/efi and / separate. Idk why but it works fine I guess and I'm afraid to do anything else.

>>106477561
>>106477587
Some genius came up with the idea of sharing ESP between different disks whenever possible. Because who ever removes OS disks or wipes them clean? Best way to avoid the fuckery is to have a centralised dedicated place for it like ZFSbootmenu contained within a USB stick and not let any OS install any bootloaders of their own.

File: 1693676878853898.gif (1.06 MB, 640x640)

1.06 MB GIF

So wait with ZFSbootmenu, I can just install it to a USB and then install my entire distro under a zfs pool and ZFSbootmenu will find it and let me boot into it? Is that how it works?

>>106477792
Yes.

>>106477713
>I make /boot and /boot/efi [...] separate
They're 2 separate things with separate purposes:
>/boot/efi
This is the EFI system partition (ESP). It can be mounted at /boot/efi or /efi, it doesn't really matter (but you have to tell your bootloader where it is; systemd-boot will figure out by itself but GRUB i'm not sure).
It's required by all (U)EFI platforms so they can boot, and contains the actual bootloader at /EFI/BOOT/BOOTX64.efi (or BOOTAA64.efi for arm64, BOOTIA32.efi for x86, BOOTRV64.efi for RISC-V etc).
>/boot
This is what's called the XBOOTLDR partition. It's completely optional -- The main reason why it exists is because, if you first install Windows, your ESP might be too small to fit the kernel + initramfs (or multiple copies of them if you have multiple generations). So they made a separate partition just to store those.
If you don't dual boot and installed Linux with a clean format then you probably don't need it. When formatting my drive I use 512 MiB for the ESP so it has plenty of room for many generations of NixOS kernels+initramfs'es.
TLDR is if the only subdirectory of /boot is /boot/efi then you don't need a /boot partition. But if you choose to delete it make sure to not fuck up and accidentally delete /boot/efi, because that you do need, and deleting that will brick your system.

>>106473118
Tried it, it never detects my fucking hardware properly.

>>106476203
In essence, ZFSBootMenu is a small, self-contained Linux system that knows how to find other Linux kernels and initramfs images within ZFS filesystems.
i think ur wrong op

>>106477818
my esp is 1GB in size and fits efi binaries plus kernelshit just fine, why don't more people do this?

>>106477755
>sharing ESP between different disks
??????????
There's always one ESP per physical disk that an OS is installed on. Maybe you mean sharing between partitions?
If an OS installs its bootloader to an ESP other than the one on the target drive then it's an OS issue. It should never do that.
>ZFSbootmenu contained within a USB stick
So you have to use the USB stick to boot your system? That's retarded.
I don't know what kind of fuckery you have going on your system that necessitates this, but I have two NVMe drives, one with NixOS and one with Windows 11. Both have one ESP and one system partition. The Windows one has a recovery + reserved partitions as well because Microsoft or whatever. From what I've heard they're optional if you deploy Windows manually using diskpart + DISM instead of using the GUI Windows installer.
Either way it works perfect for me. Your system must be really fucked if you think ZBM on a USB stick is the "sane" solution.

>>106477818
Thanks for the clarification. But how does disk encryption fit into this? I encrypt / but leave a separate /boot unencrypted because that's just how you had to do it back in the day. How do I put my kernel and initramfs on /efi? Whenever I compile my kernels they automatically end up in /boot.

>>106477860
>If an OS installs its bootloader to an ESP other than the one on the target drive then it's an OS issue. It should never do that.
Idk if other OS's do it but on debian's installer it'll show the internal disk with the esp flag on /boot/efi. If you're trying to install a bootable system onto a flash drive then you have to remove that esp flag from the internal drive's /boot/efi partition then set it for the removable drive. Of course, this makes your internal drive unbootable so then you have to go in with a rescue CD and re-add that flag. It's fucking retarded.

>>106477812
neat. I was thinking of going full zfs but my existing shit is ext4 and what not. Was going to wait until a second drive came in. that may make this easier

>>106477860
>If an OS installs its bootloader to an ESP other than the one on the target drive then it's an OS issue. It should never do that.
Happens literally all the time. Pretty much every OS installer will use an existing EFI partition, even if it's on a different disk. Then when you pull or ballet that disk, the OS gets bricked on the other disk.
>So you have to use the USB stick to boot your system? That's retarded
You can have it on the same disk as an OS. To me it adds more flexibility since I can do full disk snapshots/backups and I don't need to fuck around with efi entries or worry about what disk the ESP was on again.

>>106477829
>why don't more people do this?
Idk. Probably just distro installers wanting backwards compatibility, plus people dual-booting will have a 100MB ESP already bloated with Windows stuff, so it makes sense to have split boot partitions as a safe default.

>>106477870
You can't encrypt the ESP, since it's loaded and accessed by very low level firmware. There's quite literally nothing else before the kernel is loaded from the ESP other than your firmware.
The proper way to prevent tampering with the ESP is secure boot. NixOS has Lanzaboote which signs it with your custom keys. This means the system will only boot *your* kernels + initramfs, and nothing else. It will refuse to boot other Secure Boot distros or even Windows, which I think is pretty cool. It turns the Microsoft attempted proprietary bullshit into an actual security feature.

>>106477883
Idk what an "ESP flag" is. I don't think such a thing exists. Maybe it's the GUI installer's way of expressing the ESP GPT partition type?
>If you're trying to install a bootable system onto a flash drive
See >>106477587 for how I did it with Fedora

>>106477860
>Your system must be really fucked if you think ZBM on a USB stick is the "sane" solution.
What's the problem exactly?

>>106477904
>Pretty much every OS installer will use an existing EFI partition, even if it's on a different disk
That's a bug. There should always be one ESP per drive, and it should never under any circumstance touch an ESP other than on the drive it installs to. If there's no ESP on that drive it should make one instead of using one on a different drive.
Although, I will admit, the spec doesn't really account for multiple drives:
>https://uapi-group.org/specifications/specs/boot_loader_specification/
>Otherwise, if on GPT and an ESP is found and it is large enough (let’s say at least 1G) it should be used as $BOOT
Perhaps it should be edited to clarify how it should work on multiple drives. If you read the discoverable partition spec:
>https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Then you'll see the intent is to have one ESP for each drive, and then the ESP you boot off of is the "active ESP" that then determines where your root FS is. (So it's kind of solving the opposite of the problem you're having -- it's solving finding a rootfs for an ESP instead of finding an ESP for a rootfs)

using a usb as a bootloader is kinda neat, doesn't that mean you can have a fully encrypted device where the only insecure code section is ejectable and hidden?
currently, even if you encrypt everything you still need the bootloader unencrypted to start so moving it into a usb means the device is bricked without it, it's a 2fa of sorts

>>106477870
>How do I put my kernel and initramfs on /efi?
you don't have to. the only thing /efi needs to contain is the .efi binary that decrypts your root and boots a kernel from there.

>>106477952
See >>106477561 for the guy's problem
If you're asking why it's a problem to have ZBM on a USB stick (or use ZBM at all) I just think it's unneeded complexity. I don't like having to boot a Linux distro to then... boot my Linux distro. I just wanna boot mine straight away.
Not to mention the problems that arise from using kexec -- you can search up how Linuxboot does it (same thing as ZBM but for enterprise servers) but TLDR is that it's impossible to guarantee a stable system state after using kexec, because all the kernel drivers assume the system hardware is in an uninitialized state, but after kexec some is initialized and some isn't, and it fucks both the driver's and firmware's state because of that.

>>106477972
yup

>>106477972
A better (imo) way of doing this is to have a detached LUKS header (using cryptsetup --header option) + keyfile on the USB stick, and have the kernel+initramfs signed and protected by secure boot (e.g see >>106477915 for NixOS).
Then that way you have just your ESP partition and an "other" partition that just looks like random noise due to no LUKS header. Then you simply use your USB stick to boot. You can even have a passphrase for the file to require both having the system drive, the USB stick, and knowing the passphrase to boot.
And also maybe use TPM2 PCRs (if you have a TPM2, basically it's a checksum of the system firmware that can be used as a password) to ensure the system firmware isn't tampered with. So now to boot you need the system drive, signed kernel, correct firmware hash, USB drive with header + keyfile, and passphrase. 5-factor authentication?

>>106478027
Can you still pull out the disk and decrypt it with a password if you use secureboot and TPM? I was under the impression TPM's encrypt your data using a key stored in the hardware, so if your motherboard dies then all your data dies with it.

>>106478053
No. That's kind of the point -- you need the motherboard and TPM to be untampered and fully working to decrypt. It's literally designed to prevent someone pulling out the drive and decrypting the data (e.g. stealing a drive from a laptop). That's why Windows uses it by default for BitLocker since anti-theft is all normies need.
>all your data dies with it
If you're a dumbass without any data backups then yeah. But you'd also lose your data if your drive dies or gets corrupted, or if your drive gets radiation from the sun at just the right angle so the drive headers gets bitflipped. In all these cases it's your fault for not having backups.

>>106478074
If you have backups of the data that don't rely on your TPM keys then that kind of defeats the entire purpose of using TPM in the first place.

>>106429290
It is moral to attempt keep of an index for things The Fairy Queen is known to consider "salvageable"

>>106478081
Not really. Again the main point of TPM-backed encryption is anti-theft to prevent stealing data from pulling drives from laptops. If you do backups to a remote server in your home that has disk encryption then it's still secure. Maybe then you require that server to enter a passphrase on bootup.
And don't forget you can have multiple LUKS keys. On my systems I use TPM+PIN as the main decrypt key but have a recovery key in case the TPM gets hosed for whatever reason. So far I've thankfully hadn't had to use it, but if it does, I have that key synced via Syncthing to my phone and desktop PC. So as long as none of the 3 die at the same time I'm good.

https://www.youtube.com/watch?v=V7V3kmJDHTA
I seriously hope you guys don't use ZFS. It will kill your SSDs

>>106478099
>multiple LUKS keys
(Btw this is why LUKS is far better than ZFS encryption if you only have a single drive. You can't do this with ZFS, but you also can't use LUKS across multiple drives and decrypt them at once like you can ZFS)

>>106478118
im pretty sure zfs supports multiple key files or do you mean as in required multiple?

>>106478074
It would suck if your TPM died and you went to restore from a backup only to find the backup was dead as well. Knowing that your actual main drive was perfectly functional but the key was erased because your mobo shit itself. Seems like another point of failure waiting to happen. I'd rather just encrypt with a password.

>>106478130
Not natively. It can only have one wrapping key at a time unless you use some external "wrapper-wrapper" key management mechanism. It also doesn't support TPM natively. You need to put a bunch of shellscripts in initramfs to handle it.
With LUKS it's built-in, you can add and delete new keyslots with TPM, keyfiles, recovery keys just using cryptsetup.

>>106478074
Since you seem to know about backup strategies, how would you ensure data integrity in the following case?
>doing work on a laptop (only 1 hard drive bay)
>internet not available (no cloud backups)
>have to move around frequently (makes keeping a USB HDD plugged in impractical)
I find myself in this situation pretty often when I'm traveling. The best solution I can come up with is to keep an SD card plugged in, which is helpful because it doesn't protrude from the laptop, and set up a zfs or btrfs mirror for my work directory. Writing to 2 different mediums at once, both with checksummed files where possible corruption will be detected upon a scrub or next time the file is read should be pretty much bulletproof right? If the internal drive's files get corrupted there's another copy to restore from on the SD card.

>>106478144
>It would suck if your TPM died
This is why you always use another keyslot with TPM, e.g. recovery key or password.
>only to find the backup was dead as well
User error for having bad backup strategy and not verifying the backups still work. If you do snapshot based backups like zfs or btrfs send/receive then it's not an issue unless something's seriously wrong with your drives.
But at that point it's just "it would suck if your drive died and your backup was dead too". Yes, it would suck. Not much you can do about it other than get a better backup strategy.
>I'd rather just encrypt with a password.
You can think of TPM as an optional speedup to existing decryption methods like password, rather than replacing them. So if your firmware and secure boot state (optionally kernel, initramfs, BIOS config) is the exact same as last boot, it will let you through and save you the time of having to type in a long password.

Personally I think the real future is to have one single password that's used for both disk decryption and log into your user account, and pass that password to your display manager so it uses it to log you in without having to type in the password twice. It's possible with pam_systemd_loadkey but I haven't quite figured it out yet.

>>106478195
For my laptop I'm a macfag so I just have a Time Machine SMB server that I access over WireGuard and it just backs up in the background whenever I have a network connection. For my desktop it's sending btrfs snapshots to that same server, and only keeping last few daily/weekly/monthly/yearly snapshots.
But, if
>internet not available (no cloud backups)
then I would say just having a big external SSD or SD card that you occasionally sync up with using btrfs/zfs snapshots is sufficient. If by
>a zfs or btrfs mirror for my work directory
you mean like having two vdevs on your main drive that are mirrored? Or having two internal drives? Sounds like a pretty good idea as well, although the latter is significantly better over the former since it will protect against e.g. controller failures or similar errors at the drive level.

>>106476917

you mean windows partition i do not have one

>>106478280
NTA but I do think he means ESP. UEFI does actually support drivers. By default most firmwares only has FAT32 drivers (this is why the ESP must be FAT32), but you can load any FS driver into UEFI and extend it to read other filesystems.
And also how the fuck would installing drivers into the Windows partition change anything about the boot process?

>>106478293
Here:
>https://efi.akeo.ie/
>The following links include binaries for AFFS (Amiga Fast FileSystem), BFS (BeOS FileSystem), Btrfs, exFAT, ext2/ext3/ext4, EROFS, F2FS, HFS and HFS+ (Mac OS, including compression support), ISO9660, JFS (Journaled FileSystem), nilfs2, NTFS (including compression support), ReiserFS, SFS (Amiga Smart FileSystem), UDF, UFS/FFS, UFS2/FFS2, XFS, ZFS and more.

You will not trick me into using UEFI

>>106478333
Lmfao. Because yes, of course 16 bit real-mode environment on your 64 bit CPU is better.
Unless you're running a literal toaster from 2003, UEFI is better in every way.

>>106478359
Nice try, Shalom!

>>106478211
You bring up good points. I didn't realize you can have a separate password-only key that works as an alternative to the TMP key.
I'm trying to improve my backup strategy but I don't have unlimited funds. It's a very real possibility my laptop could shit itself at the same time that my house could burn down, then I'd have to drive halfway across the country to recover my offsite backup at my mom's house to find that she developed dementia and used my hard drive as a frisbee.

>>106478254
I just read that you can't trust SSD firmware to not just write one copy of the file if you try copies=2 with ZFS on the same drive, so the only real solution to data corruption is to always have a copy on another device. Some cameras come with 2 SD card slots for this sole purpose, to write to both in case one fails. I guess I'll have to invest in an SD card the same size as my SSD if I want to feel safe. Even then I have to worry about my laptop getting stolen or getting fried when the chink USB-C cable decides to kill it when I plug it in, so perhaps keeping daily backups to a 3rd device is necessary.

>>106478399
In terms of backups anything really is better than nothing. For example before I had my NAS, my main "backup" method was Syncthing to sync across devices, with staggered versioning so Syncthing would keep the last X past versions of files. And I only did it on a few critical files, mostly my passwords database, Obsidian vault, and photos from my phone. I still use it but much less as a backup solution and more as a mobile sync solution, aka what it was intended for. But it got me through until I got the NAS, and saved my ass when my keepass database got corrupted once.

>>106478436
Yeah some SSDs do block-level deduplication and stuff like that. It makes sense, to conserve space and all that. Maybe it can be mitigated with encryption, since the encrypted data will (hopefully?) be different for the two same files?
Personally in your position I would invest in the "most security" option first, and "least security" last. Aka I would focus on the daily backups first. That'll give you the most protection since the e.g. external SSD is completely external and avoids like you said data theft or other stuff that can happen when it's all on one device. The SD card stuff I would only pursue if you make tons of changes and need backups to the precision of an hour or a minute.

>>106477685
i get what you're saying. but from a usability point of view it's a putaytah puhtahta, you're still loading a thing so it can load another thing, unless there's some advantage in relegating the same task to EFI shell specifically that i'm not aware off.

>>106477987
>I just think it's unneeded complexity. I don't like having to boot a Linux distro to then... boot my Linux distro. I just wanna boot mine straight away.
again, that's more of a conceptual complexity than a practical one

>>106480081
>more of a conceptual complexity than a practical one
Well, yeah but there's a massive difference between just loading a bootloader EFI binary, and loading a bootloader + kernel + userspace in initramfs, which then kexec's your real OS.
If you want fast boot times or flickerfree boot then you don't really have a choice.
On my machines I use systemd-boot with a timeout of 0, so I don't even see a bootloader at all, it just goes straight to booting my OS with zero delay. I can still access the boot menu by holding the spacebar as it boots, which will bring up the menu seen in >>106477333.

>>106478109
Only retards use ZFS-on-root on Linux. Btrfs does everything you require of a rootfs (snapshots, replications via send-recieve) and is native to the Linux kernel.

>>106478118
>you also can't use LUKS across multiple drives and decrypt them at once like you can ZFS
umm, acshually you can? Simply encrypt each drive with the same passphrase/keyfile and then list each drive in /etc/crypttab with the desired mapped name.

>>106480255
Yea but it's not a "native" solution like ZFS is. Unless you hardcode your passphrase you'll still be entering it for each drive individually, unless you write a shell script to pipe it to cryptsetup or something. ZFS does it on a dataset level where you type it once and it does operations on the whole dataset.

>>106480284
No, if you use systemd for unlocking your encrypted drives. If all of them are encrypted with the same passphrase, you only need to type it once since systemd caches it.

>>106473118
btrfs equivalent of this?

>>106480176
It's not native to the RHEL kernel, unfortunately. That was a big reason I went all-in with ZFS. I was already enjoying RHEL and ZFS on TrueNAS. OpenZFS building kmods for RHEL was a neat bonus. Plus, ZFSBootMenu is undeniably cool.

Why?
What practical, real world problem is this solving?
I'm genuinely curious.

>>106473118
Sorry, but isn't ZFS obsolete?

>>106480110
What I want is to not have to worry about bootloader conflicts or disappearing EFI boot entries. If having reliability for that kind of stuff in the current year means having to dedicate a mini-OS on a USB for it, then so be it.

>>106480611
Like I said before if you have those issues your system is really fucked up. Never had any of this in 3 years of using Linux as a desktop, works on my machine, etc etc.
>disappearing EFI boot entries
This one especially is concerning. If the ESPs get overwritten it makes sense but entries should never disappear by themselves

>>106480603
ZFS is the best FS right now.

>>106480176
Btrfs is unreliable trash thats breaking every few months. ZFS doesnt have that problem.
One example: https://lore.kernel.org/linux-btrfs/283624a8-dc79-4dd0-b6e5-9d5e83e31648@gmx.com/T/#ma9fa3134de084a38c2b208def66619e7a8561085

>>106480779
Perhaps I do more bare metal OS installations and swapping/wiping of OS disks than the average person. Perhaps every MSI board that I've used over the last decade has the same shitty, buggy UEFI. Whatever the case, my experience with UEFI has been pure ass since day 1. At this point, I've had enough of mitigating and hoping for the best - I want that bullshit contained. I have thought about returning to monke, but insisting on legacy boot seems more and more silly with every passing year. Maybe there's a more elegant, more Linux-native solution out there, but for now ZBM delivers - and so does ZFS in general.

>>106480887
Faggit, zfs fucks your data up randomly on encrypted datasets
https://github.com/openzfs/zfs/issues/10507
https://github.com/openzfs/zfs/issues/12014
https://github.com/openzfs/zfs/issues/15526

>>106480964
never had any problems in 10 years with zfs, compared to the many corruption/log etc. errors with btrfs in only 1-2 years. Most of your issues are in very specific cases, while the btrfs stuff happened to everyone using newer kernels.

>>106480176
>btrfs shill
kek

>>106480964
Why would you ever want to send an encrypted dataset over the wire as decrypted?

>>106482127
Because the system on the other side uses its own encryption key that is different from yours?
Anyway, there is also a zfs bug where simply creating a snapshot of an encrypted dataset might corrupt your data. They even wanted to declare zfs's native encryption an "experimental feature" because they couldn't determine the cause of the issue.

>>106482206
>Because the system on the other side uses its own encryption key that is different from yours?
Still seems stupid and more importantly wasteful.
> there is also a zfs bug where simply creating a snapshot of an encrypted dataset might corrupt your data.
Doubt, I've been snapshotting my encrypted datasets for years without issues.

XFS + Stratis is the future. There's a reason why it's RHEL's supported and recommended path forward. Btrfs is a dumpster file that RHEL doesn't even want to touch anymore and ZFS is poorly supported trash as well.

>>106482458
redpill us then, fren

Why come into a thread saying things like it's "the future" and "there's a reason" if you're not gonna back it up? Guess I'll proceed with my RHEL install on ZFS as normal.

>>106482206
The problem was only repeatable on encrypted pools, individual datasets weren't affected afaik.
I encrypted my whole pool and suffered data corruption. Nothing drastic but some images got fucked up. It's a lot better now.