rEFInd is _so_ much simpler: one efi entry, one text config file in the efi partition, nothing that needs to change when the kernel updates, and no massive pile of templating and moving parts to mysteriously break dumping you at an impenetrable grub “rescue” shell.
ciupicri 21 hours ago [-]
I'm using rEFInd because it can load and use the NVMe EFI driver unlike GRUB and systemd-boot. rEFInd is a true UEFI boot loader.
I think that Fedora doesn't know to update its configuration when I install or remove a kernel, so I use rEFInd only to run systemd-boot which is pretty well supported by Fedora. I could probably try letting rEFInd scan the boot partition for kernels or modify/tune kernel-install [1], but why fix something that's not broken?
As a side note, I don't like how by default rEFInd does some things automatically and how it makes the boot menu kind of bloated. I had to do configure it a bit, but at least it lets you include separate configuration files that override the defaults or add menu entries. This is why I don't consider it quite simple; I prefer the more minimalist approach of systemd-boot.
Systemd-boot is my choice for any simple boot scenario. Love it. Agreed that grub is a mess
100ms 24 hours ago [-]
does refind support secure boot and measured boot? I loathe pretty much anything systemd but systemd-boot gives me this with zero effort, and it's legitimately useful
coredog64 22 hours ago [-]
Secure boot, yes: I just had to futz with that a few weeks back when the CUDA toolkit installed Nvidia-signed drivers.
DaSHacka 1 days ago [-]
There's also systemd-boot, which seems to be getting more popular.
That's what I'm currently using in gentoo and it's fine. Realistically there's only 1 config file to modify if I want to change kernel settings and otherwise it just works.
That said, I'm probably going to try a straight EFI boot on my next laptop.
Type2 loader entries are just UKIs[1]. I don't know what you are implying with "systemd-boot's automatic sourcing of UKIs isn't a BLS thing"? Any way I try to interpret it, neither would the Type1 entries fall under the definition of automatic sourcing (neither anything any other bootloader does).
TBH I've only used it for Hackintoshes and BSDs. I don't know why you'd want it.
But I am finding this hard to post on account of this big hairy grey thing with a long prehensile nose that's in the way...
They only work on UEFI. I don't like UEFI. I have kit in near-daily use that doesn't have UEFI at all.
GRUB works on BIOS, UEFI, x86, Arm, whatever. It boots Linux, all the BSDs, Haiku, whatever. So GRUB wins.
I hate GRUB for its hostility and unfriendliness and impenetrability... But it does the job on more kit than, well, any of the alternatives.
p_l 22 hours ago [-]
You haven't upgraded any x86 compatible beyond 2005? /s
lproven 3 hours ago [-]
/s notwithstanding... no.
I run a bunch of decade-old HP Microservers. All BIOS-only.
My personal laptops are old Thinkpads, from before the keyboards went crappy & Lenovo took away the expansion options. So they're all about 15, ?20 generation at the newest, but they are all maxed-out and go like stink. BIOS boot mode optional.
My default hypervisor is VirtualBox, because it runs the same on Linux, Windows and Mac. Defaults to BIOS boot.
This is not like some ancient history. All run current OSes and distros.
aslihana 21 hours ago [-]
Loved that too much hahaha: “friends don’t let friends use grub”.
rEFInd seemed best for me too
utrack 23 hours ago [-]
does it support encrypted /boot though?
stirfish 21 hours ago [-]
Back when the earth was still cooling, I remember having to choose between grub and lilo. Who wants a little worm in their computer? I went with Lilo.
Now I use grub, because I don't know much better. I'll check out rEFINd.
majorchord 22 hours ago [-]
Friends don't let friends perpetuate harmful dogmatic FUD that lacks nuance and perspective.
cwillu 21 hours ago [-]
Calling an opinion you don't like FUD doesn't make that opinion wrong, harmful, or dogmatic.
stereo-highway 20 hours ago [-]
This post generated more attention than I expected. I wanted to share something that i got working at home on consumer hardware and with software that I’m slightly more familiar with.
This is by no means the only way to implement this, an I’m sure there are better ways.
Thank you for the feedback, I’ll edit it and add more points on alternative stacks and the iSCSI network pickiness.
deathanatos 1 days ago [-]
> 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 that'd be kind of an unusual setup, and I thought most of us booting w/ EFI were doing so with Grub.)
yjftsjthsd-h 1 days ago [-]
Even if you do CONFIG_EFI_STUB, there should be a post-update hook to automatically call efibootmgr.
nicman23 1 days ago [-]
or just copy the latest kernel to something like /vmlinux and /initramfs
creshal 1 days ago [-]
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).
cwillu 1 days ago [-]
Grub2 is scary and complicated. Remove grub from the equation, and all the scary goes away.
creshal 23 hours ago [-]
Grub is really impressive in how it consistently spent the last 30 years focused on improving everything except the UX of the one workflow 99.99% of its involuntary users need it for (boot linux as reliably as possible, and make it easy to debug when it does not).
nicman23 1 days ago [-]
grub is just a operating system. it is quite good when shit hits the fan
creshal 23 hours ago [-]
~90% of the failure modes grub can fix don't exist without grub. I can't remember any time when its needless complexity was actually a net benefit compared to literally any of its alternatives (and between gummiboot/syslinux/efilinux/isolinux/systemd-boot/efistub I've used a lot of them).
nicman23 21 hours ago [-]
i like grub, but i also remember pre-0.98 grub
awesomeusername 7 hours ago [-]
i love HN but also starting to think it's time for us oldies to have our own one: cost of entry, having a distant memory of booting linux from a floppy
nicman23 6 hours ago [-]
i have the memory of bios being so shit that i had to boot grub from a floppy to boot from a cd
nicman23 1 days ago [-]
i never got it to work
nubinetwork 1 days ago [-]
I have 2 entries, /efi/current.efi and /efi/old.efi... when I upgrade, I copy current to old, and copy my new kernel out of /boot as current and reboot.
yjftsjthsd-h 1 days ago [-]
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?
rwmj 21 hours ago [-]
We've spent a lot of time over the last decade making NBD a faster and better protocol: pipelined requests, full support for trim and zeroing, load balancing over multiple connections, a proper specification, new client and server implementations (libnbd, nbdkit), standard command line tooling, interop testing between all the implementations, and a formal URI specification. It's very trivial to set up an NBD server and there's tons of documentation about how to connect to it with different clients (start here: https://gitlab.com/nbdkit/nbdkithttps://libguestfs.org/nbdkit.1.html#SEE-ALSO).
Unfortunately in this specific case (diskless booting) dracut support still sucks, which I really need to get around to fixing at some point.
guenthert 1 days ago [-]
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.
Modified3019 1 days ago [-]
I don’t have direct experience, but when I looked into it my takeaway that NBD was unable to reliably deal with network interruptions as well as iscsi.
We did something similar with Ubuntu LTSP 10 years ago. Had tens of diskless office computers as fat clients booting from a single server and running everything in ram.
Update? Just rebuild the base image and reboot the stations.
Way better than any windows setups for offices, where you need many identical stations.
dhash 1 days ago [-]
something worth mentioning here is that iSCSI is quite unhappy on congested networks or packet loss caused by incast traffic.
to make this actually work well, consider modifying your switches QoS settings to carve out a priority VLAN for iSCSI traffic
fragmede 1 days ago [-]
or a north-south/east-west architecture, so there's an entirely separate network just for iSCSI. Control plane vs data plane.
anonymousiam 1 days ago [-]
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 once I'm done, accessing an iSCSI drive over 10GbE will be 4-8 times slower than a local NVMe drive, but it will sure be a lot better than it was!
Ideally, I could run VMs on the NAS and have great performance, but that's another hardware upgrade...
olavgg 1 days ago [-]
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.
RulerOf 12 hours ago [-]
> Another alternative is Mellanox with RDMA. You need CX4+ for optimal performance over TCP/IP, while the cheap CX3 is excellent with IPoIB.
Do these benefit the iSCSI target end of the equation too, or just the initiator? And do they work like an HBA, where you configure the card in a firmware setup menu, or does it just transparently accelerate the software initiator on Windows/Linux?
ReDress 1 days ago [-]
Really I wonder how this turns out to be diskless while you're clearly accessing a disk/drive over the network. Shouldn't we refer to this as network boot?
pdpi 1 days ago [-]
It's diskless from the point of view of the device being booted.
Tepix 1 days ago [-]
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...
rwmj 1 days ago [-]
iSCSI seems intentionally obscure. One of the improvements I made to NBD was invent a simple, standardized URI format so that you can specify servers easily, eg:
NBD looks pretty nice! I've been eyeing it from afar for a while.
How well does it work in environments with noticeable network latency?
rwmj 24 hours ago [-]
Requests and responses are pipelined so at least you're not serializing on round trips. However fundamentally if there is lots of latency, then you're going to be affected in some way. Usually we see problems where the OS accessing the remote drive times out which can sometimes be worked around by increasing timeouts, if you can work out how. (Latency is going to affect every block device protocol in about the same way)
You can actually see what happens quite easily if you've got an OS image handy. With a Fedora VM image:
("$uri" expands to the NBD URI of the nbdkit server which qemu can parse natively)
Even that 1 second delay is painful since it turns out that booting is quite serialized. Edit: I turned down the latency to 50ms in the example which is a bit more realistic. Still painful.
burner420042 1 days ago [-]
The 'target' moves slow so once you learn it, it all stays relevant forever.
... And it's very, very fun.
Tepix 1 days ago [-]
Does it offer performance advantages over NFS root?
burner420042 23 hours ago [-]
They operate at different layers.
iscsi is a block device: you gain a 'disk drive' sitting on your network.
A dedicated network for disk traffic and use it to host on-prem virtualization. It's called a SAN array.
Tepix 20 hours ago [-]
Sure, but eventually you will reach a layer with files, usually. Then you can run benchmarks and compare numbers.
a96 1 days ago [-]
I kind of expect the performance is worse, but one neat thing is that iscsi is a block device, so you could run e.g. disk crypto, volume management or whatever on it. Not to mention any FS. And you don't need to deal with NFS or RPC.
bobmcnamara 24 hours ago [-]
Dunno about performance vs NFS, but I've stuffed an unaware OS onto ZVOL-over-iSCSI using a NIC with option ROM.
throw0101c 20 hours ago [-]
Still miss the Open Firmware (IEEE 1275) "boot net" from my Sun Solaris days (and PowerPC Macs).
I used similar ipxe setup for robotic cluster - every robot booted from the same thing, then kubernetes managed the containe orchestration. it was fun.
ggm 1 days ago [-]
NFS diskless is the more common approach I've used but this is very cool.
KaiserPro 1 days ago [-]
NFS diskless was easier for me to setup when I was doing it.
THe caveat was, you needed readonly root, so that meant freezing the OS, anything that needed changing was either stored in a ram disk (that you need to setup) or a per host nfs area (kinda like overlayfs, but not)
yjftsjthsd-h 1 days ago [-]
Why would you need a read-only root? Do you mean to share across multiple machines?
KaiserPro 1 days ago [-]
Yeah it makes things a bit easier to debug. Originally my system was designed to run on multiple machines at once.
If you needed to update the root dir, you chrooted into it and did the (yum) update.
ahepp 1 days ago [-]
When I tried root-on-nfs I had a lot of issues. The Redhat and Arch package managers don't seem to like it (presumably a sqlite thing?).
contingencies 1 days ago [-]
You can download the rootfs, extract it to a ramdisk, and just run in memory. This is fast for everything. Unfortunately, memory just got super expensive. Fortunately, Linux requires ~no memory to do many useful things.
ahepp 1 days ago [-]
You might find it worth upgrading to 10gbps if you continue to go down this road. The Mikrotik CRS-309 has served me well, and a couple Intel X520-DA2s. I believe those NICs can do iSCSI natively, and pass the session to the operating system with iBFT.
SFP28 might be cheap enough now too, I'm not sure...
guenthert 1 days ago [-]
"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.
snailmailman 1 days ago [-]
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.
kuglimon 23 hours ago [-]
I've never had this experience dual-booting, neither with UEFI nor Grub. I've been using Linux for nearly 15 years, 13 of those dual booting. Dozens of systems from laptops to desktops. Windows would always purge the boot entries. I'd have to manually fix booting, constantly. This happened with Ubuntu, Arch Linux and recently NixOS and through all the Windows editions till 11. I had to install Windows for a lan party recently and lo and behold on the second day NixOS is gone from the boot list and unbootable. Nothing of value is lost when it gets purged, but it's a damn annoying tax to pay just to be able to play video games.
Luckily gaming now works well enough that the only reason to use Windows was gone. Well, apart from some online games played during lan parties.
jeroenhd 1 days ago [-]
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.
charcircuit 1 days ago [-]
>Not really Linux' fault
If Linux corrupts someone files, it is 100% Linux's fault and is absolutely unacceptable.
pbhjpbhj 1 days ago [-]
SecureBoot is a PITA.
jeroenhd 1 days ago [-]
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.
a96 1 days ago [-]
Very neat. I've never seen the Debian installer using iscsi. No other installer either for that matter.
Looks like ZFS is only used to store the image on the server, though. I was expecting this to be more interesting because of that.
Pretty cool! You could also boot into an ephemeral minimal initrd that displays a selection menu instead of doing it in iPXE. That would grab the new kernel and initrd from the network and kexecs it without reboot.
theandrewbailey 1 days ago [-]
> You could also boot into an ephemeral minimal initrd
Wouldn't that need a local disk?
wallst07 1 days ago [-]
No. PXE boots routinely load the kernel and initramfs directly into RAM with no local disk involved. The initramfs then mounts the real root FS over the network.
Then anaconda or whatover os installer picks up and installs the OS in a PXE install sequence when there is a local disk.
virusduck 19 hours ago [-]
It's true. This boot has no disk
aidenn0 13 hours ago [-]
Your comment makes me hope that the hostname of the machine is walter-peck.
spacecow 21 hours ago [-]
Heartwarming to see iSCSI still in use! I originally made this account while certifying devices against good ol' RFC 3720 at an interop lab quite a long time ago now...
ersoft 23 hours ago [-]
iSCSI is great and underated, I've been running iSCSI volumes for OrangePI boards which had only SD card support for years. Performance was much better on Gigabit Ethernet vs the SD card.
Ansible? Amazing amount of complexity for something so simple. Sigh ... Linux. It's just a commercial toaster to me these days.
I net boot 9front and it takes 5 minutes to setup. Plus it's all built in so you don't need to install anything. Just enable tfp and dhcp on the 9 machine (no issue for me since 9 runs my network) then setup a few lines in your ndb file for the machine you want to boot which includes Mac, IP and boot image file. Then you need a simple plan9.ini and boot scripts for the machine in /cfg/. Last, a quick change to the root file server to listen on IP Then power on the machine and it boots from the same root fs so your starting at your desktop on a new machine. Done. Why make something so awesome so difficult?
yjftsjthsd-h 20 hours ago [-]
> no issue for me since 9 runs my network
That's more interesting than the netboot thing. Is 9front running your router? What do you do for WiFi? Have you written this up, and/or could you point me to any references for doing it?
However, at the moment my network is in shambles so I'm only running 9front for dhcp/dns/tftp. Lots of life things so I haven't had time to properly setup everything.
Wi-Fi is handled through a freebie unifi AP friend gave me. I run the controller in a docker manually when needed.
verytrivial 1 days ago [-]
I know it was just a convenient pretext for a learning journey, but do not come away from this thinking llama.cpp needs to be compiled on Windows before use. The GitHib project has a cornucopia of pre-built artifacts to use.
what i want to play with is rdma and having a bcache block device with the remote as a backing and a small local nvme as a write-through cache
MohammadAbuG 1 days ago [-]
This man is diskless
iberator 1 days ago [-]
Does zfs support error correcting instead of just finding (already) broken files?
I have been waiting for such a feature for like 15 years now. Without it, zfs is just a fad and useless filesystem (all that complexity for NOTHING).
ext2 for the win! still
tecleandor 1 days ago [-]
I don't know if I'm understanding your question, but ZFS actively corrects data on disk when it finds a checksum error [0]. Those checksum errors can be found when accessing that data, or doing a 'scrub' action that scans the whole volume to check integrity.
ZFS supports self healing, you do not have scrub, it will be corrected during a bad read as long you have a copy. Metadata has 2 copies by default for additional safety for a single disk.
shevy-java 1 days ago [-]
I have to admit, I misread "Diskless Linux" initially ...
louwrentius 1 days ago [-]
I would probably recommend to look into NVMe over TCP over iSCSI, especially for fast NVMe drives.
darig 1 days ago [-]
[dead]
qzgrid37 1 days ago [-]
[dead]
Rendered at 11:33:25 GMT+0000 (Coordinated Universal Time) with Vercel.
rEFInd is _so_ much simpler: one efi entry, one text config file in the efi partition, nothing that needs to change when the kernel updates, and no massive pile of templating and moving parts to mysteriously break dumping you at an impenetrable grub “rescue” shell.
I think that Fedora doesn't know to update its configuration when I install or remove a kernel, so I use rEFInd only to run systemd-boot which is pretty well supported by Fedora. I could probably try letting rEFInd scan the boot partition for kernels or modify/tune kernel-install [1], but why fix something that's not broken?
As a side note, I don't like how by default rEFInd does some things automatically and how it makes the boot menu kind of bloated. I had to do configure it a bit, but at least it lets you include separate configuration files that override the defaults or add menu entries. This is why I don't consider it quite simple; I prefer the more minimalist approach of systemd-boot.
[1]: https://www.freedesktop.org/software/systemd/man/latest/kern...
https://systemd.io/BOOT/
That said, I'm probably going to try a straight EFI boot on my next laptop.
https://wiki.gentoo.org/wiki/EFI_stub
I had to do it a bunch and after many many times I still couldn't remember without looking at my notes
Which ones? If you want to all you need is a single UKI in /EFI/Linux and everything is synthesized from that.
https://uapi-group.org/specifications/specs/boot_loader_spec...
[1]: https://uapi-group.org/specifications/specs/boot_loader_spec...
TBH I've only used it for Hackintoshes and BSDs. I don't know why you'd want it.
But I am finding this hard to post on account of this big hairy grey thing with a long prehensile nose that's in the way...
They only work on UEFI. I don't like UEFI. I have kit in near-daily use that doesn't have UEFI at all.
GRUB works on BIOS, UEFI, x86, Arm, whatever. It boots Linux, all the BSDs, Haiku, whatever. So GRUB wins.
I hate GRUB for its hostility and unfriendliness and impenetrability... But it does the job on more kit than, well, any of the alternatives.
I run a bunch of decade-old HP Microservers. All BIOS-only.
My personal laptops are old Thinkpads, from before the keyboards went crappy & Lenovo took away the expansion options. So they're all about 15, ?20 generation at the newest, but they are all maxed-out and go like stink. BIOS boot mode optional.
My default hypervisor is VirtualBox, because it runs the same on Linux, Windows and Mac. Defaults to BIOS boot.
This is not like some ancient history. All run current OSes and distros.
rEFInd seemed best for me too
Now I use grub, because I don't know much better. I'll check out rEFINd.
This is by no means the only way to implement this, an I’m sure there are better ways.
Thank you for the feedback, I’ll edit it and add more points on alternative stacks and the iSCSI network pickiness.
… 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 that'd be kind of an unusual setup, and I thought most of us booting w/ EFI were doing so with Grub.)
Does anyone have an opinion on iSCSI vs NBD?
Unfortunately in this specific case (diskless booting) dracut support still sucks, which I really need to get around to fixing at some point.
https://forums.gentoo.org/viewtopic.php?p=4895771&sid=f9b7ac...
https://github.com/NetworkBlockDevice/nbd/issues/93
Whether that’s the case with the latest version, I don’t know, but it’s something you might test if you choose to try it.
But this idea or ones much like it have been presented before...
"Hassle-free diskless Virtual Machines with Xen and Alpine Linux"
https://jonnytyers.wordpress.com/2016/08/16/hassle-free-disk...
"How to make a Diskless Virtual Machine (KVM)"
https://github.com/lispydev/diskless-kvm
And if you just want a dead easy PXE server for bare metal...
https://www.iventoy.com/en/index.html
to make this actually work well, consider modifying your switches QoS settings to carve out a priority VLAN for iSCSI traffic
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 once I'm done, accessing an iSCSI drive over 10GbE will be 4-8 times slower than a local NVMe drive, but it will sure be a lot better than it was!
Ideally, I could run VMs on the NAS and have great performance, but that's another hardware upgrade...
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.
Do these benefit the iSCSI target end of the equation too, or just the initiator? And do they work like an HBA, where you configure the card in a firmware setup menu, or does it just transparently accelerate the software initiator on Windows/Linux?
How well does it work in environments with noticeable network latency?
You can actually see what happens quite easily if you've got an OS image handy. With a Fedora VM image:
("$uri" expands to the NBD URI of the nbdkit server which qemu can parse natively)Even that 1 second delay is painful since it turns out that booting is quite serialized. Edit: I turned down the latency to 50ms in the example which is a bit more realistic. Still painful.
... And it's very, very fun.
iscsi is a block device: you gain a 'disk drive' sitting on your network. A dedicated network for disk traffic and use it to host on-prem virtualization. It's called a SAN array.
* https://en.wikipedia.org/wiki/Open_Firmware
THe caveat was, you needed readonly root, so that meant freezing the OS, anything that needed changing was either stored in a ram disk (that you need to setup) or a per host nfs area (kinda like overlayfs, but not)
If you needed to update the root dir, you chrooted into it and did the (yum) update.
SFP28 might be cheap enough now too, I'm not sure...
Hmmh? I haven't done so in years, but configuring multi-boot used to be considerably easier than disk-less operation.
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.
Luckily gaming now works well enough that the only reason to use Windows was gone. Well, apart from some online games played during lan parties.
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.
If Linux corrupts someone files, it is 100% Linux's fault and is absolutely unacceptable.
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.
Looks like ZFS is only used to store the image on the server, though. I was expecting this to be more interesting because of that.
Wouldn't that need a local disk?
Then anaconda or whatover os installer picks up and installs the OS in a PXE install sequence when there is a local disk.
Ansible? Amazing amount of complexity for something so simple. Sigh ... Linux. It's just a commercial toaster to me these days.
I net boot 9front and it takes 5 minutes to setup. Plus it's all built in so you don't need to install anything. Just enable tfp and dhcp on the 9 machine (no issue for me since 9 runs my network) then setup a few lines in your ndb file for the machine you want to boot which includes Mac, IP and boot image file. Then you need a simple plan9.ini and boot scripts for the machine in /cfg/. Last, a quick change to the root file server to listen on IP Then power on the machine and it boots from the same root fs so your starting at your desktop on a new machine. Done. Why make something so awesome so difficult?
That's more interesting than the netboot thing. Is 9front running your router? What do you do for WiFi? Have you written this up, and/or could you point me to any references for doing it?
However, at the moment my network is in shambles so I'm only running 9front for dhcp/dns/tftp. Lots of life things so I haven't had time to properly setup everything.
Wi-Fi is handled through a freebie unifi AP friend gave me. I run the controller in a docker manually when needed.
https://github.com/ggml-org/llama.cpp/releases
I have been waiting for such a feature for like 15 years now. Without it, zfs is just a fad and useless filesystem (all that complexity for NOTHING).
ext2 for the win! still
--