Live data from Hacker News

Diskless Linux boot using ZFS, iSCSI and PXE

aniket.foo

31–40 of 108 posts

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#31

Nice. I'm extra fond of ZFS backed network root filesystem, because it lets you put an OS on ZFS without needing to deal with ZFS support in that OS. (One of these days I want to try OpenBSD with its root on NFS on ZFS, either from Linux or FreeBSD.) Does anyone have an opinion on iSCSI vs NBD?

Well, iSCSI is a standard, so chances are better that it's supported in a non-Linux OS, e.g. MS Windows. Years ago I booted a Windows (7, iirc) client that way, but gave up on it (too much hassle and performance limited by the network) when SSDs became cheap.

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#32

"I didn’t want to get into the hassle of repartitioning everything that the boot loader works with both Linux & Windows." Hmmh? I haven't done so in years, but configuring multi-boot used to be considerably easier than disk-less operation.

SecureBoot is a PITA.

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#33

"I didn’t want to get into the hassle of repartitioning everything that the boot loader works with both Linux & Windows." Hmmh? I haven't done so in years, but configuring multi-boot used to be considerably easier than disk-less operation.

SecureBoot is a PITA.

For Debian and most other distros, secure boot isn't a problem. Installers are all using a signed, trusted-by-default bootloader.

There are some exceptions (some hardware from Microsoft doesn't trust the third party certificate used, for instance, and Red Hat Enterprise has their own root of trust if you opt into that), but they're very rarely ever an issue.

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#34

"I didn’t want to get into the hassle of repartitioning everything that the boot loader works with both Linux & Windows." Hmmh? I haven't done so in years, but configuring multi-boot used to be considerably easier than disk-less operation.

The Debian installer is less than optimal for repartitioning.

The Linux NTFS resizing code also has a tendency to trigger data corruption. Not really Linux' fault, but it's a good reason to do partitioning from inside of Windows, which can be a pain already.

Another issue I've run into is Windows creating a very small (~300MiB) EFI partition that barely fits the Windows bootloader, let alone a Linux bootloader and kernel. You can resize and recreate the partition of course, but reconfiguring Windows to use a different boot partition is a special kind of hell I try to avoid.

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#35

I've done a lot of headless/diskless stuff. I haven't done much for years, because my NAS only has gigabit Ethernet ports. I can cascade them and get four Gbps downstream, but it's still painful. I have recently upgraded my house to 10Gbps Ethernet, with only one room still stuck at gigabit, and unfortunately, it's my main office. I'm working on getting the drop there now (literally, just taking a break here). Even o…

Using a proper NIC (Chelsio) with their iSCSI accelerator will boost your iSCSI performance significantly. Another alternative is Mellanox with RDMA. You need CX4+ for optimal performance over TCP/IP, while the cheap CX3 is excellent with IPoIB. If you have a lot of packet drops and retransmissions, another option for boosting iSCSI performance is getting a network switch with a lot of memory for packet buffering. This helps with incast congestion. There are special switches with gigabytes of memory built for this.

NVMe-oF is the best protocol with least overhead for network drives, with a proper setup you lose only 10-20% latency compared to local disk even with Intel Optane. Throughput should be almost similar.

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#36

> UEFI fixes that to some extent, but it’s a pain to maintain the UEFI entries manually and change them every time the kernel updates. … you don't have to update the UEFI entries every time the kernel updates. (I guess you might if you do like a kernel w/ CONFIG_EFI_STUB, and you place the new kernel under a different filename than what the UEFI boot entry point to then you might … but I was under the impression that…

or just copy the latest kernel to something like /vmlinux and /initramfs

Or use UKI and throw the current kernel to /efi/boot/bootx64.efi; there's plenty of solutions to sane bootloader/kernel management if you're willing to invest 15 minutes into the topic and not act like it's scary and complicated (it really is the opposite).

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#38

"I didn’t want to get into the hassle of repartitioning everything that the boot loader works with both Linux & Windows." Hmmh? I haven't done so in years, but configuring multi-boot used to be considerably easier than disk-less operation.

It is relatively easy to configure. Just install Linux after windows, and Linux will generally automatically setup a boot-selection screen for you. The installer should detect windows and even shrink the partitions for you.

You can install a prettier looking boot selection menu like rEFInd, but the default works just as well, and I think the mainstream distros all setup secure boot too. On my pc it was very easy, on my (8yr old) laptop I had to add some secure boot keys and the bios was very confusing, using terms that didn’t seem to match what they should have been.

My setup has worked almost entirely flawlessly and survived updates from both OSes. Only issue being “larger” windows feature updates putting windows back as the first OS in the list, but that happens maybe once or twice a year? And it’s a quick bios change to fix the order.

Re: Diskless Linux boot using ZFS, iSCSI and PXE

#39
post #23

This could be an interesting setup for booting off a NAS like Synology or QNAP. I haven't really used iSCSI, it's intimidating how much prep this takes...

The 'target' moves slow so once you learn it, it all stays relevant forever. ... And it's very, very fun.

Does it offer performance advantages over NFS root?
Post reply on HN