Yes. In practice I think that if you set aside ZFS and release cycle mismatches the latest stable branch is better for the majority of users, since the lag for hardware support in LTS kernels is so noticeable. It comes up pretty often on Matrix. Thankfully nixos/iso-image: Support specialisations. by ElvishJerricco · Pull Request #355893 · NixOS/nixpkgs · GitHub should make an ISO boot menu choice viable.
1 Like
i had hoped and assumed that the mechanism was specialisations for the ISO. Great.
Arguably we can have the easy/gui installer also install both specialisations in the deployed system, at least as an option — because for a new user they’re going to be unsure which they want and won’t have had enough testing to yet be sure what works on their hardware etc. If they get it wrong, their inclination will be that they need to reinstall to change. Having some concrete text in their config that they can see as a way to change this is a good prompt that there’s no need to reinstall, and they can get rid of the option they don’t use later if they want.
1 Like
I think just adding boot.kernelPackages = pkgs.linuxPackages to the generated configuration.nix should be sufficient. That should teach the user that they can just change this if they need to and the kernel is important enough to justify having it in the default template IMHO.
I don’t think we should push users into specialisations as they have quite a few nasty limitations.
Agreed, though I’d say we should have a linuxPackages_lts alias and use that, because I want the implication to be about the version, not the fact that it’s linux. I don’t want people mistakenly thinking you might be able to use a non-linux kernel 
But yea specialisations out of the box for new users isn’t great, especially because of the doubled eval time and the fact that our support for specialisations with systemd-boot is significantly clunkier since we can’t have submenus.
1 Like
Fair. It just seems a lot more user- and experiment-friendly to give them two options on the boot menu, but that shouldn’t also come with other traps.
Not sure what you mean. If the ISO doesn’t boot (under VM test scenarios), the unstable channel won’t even update.
You’d be surprised how quickly that could change.
Just an hour ago this landed 
3 Likes
That is why usually the hashes are accompanied by a GPG signature to verify that nobody has tempered with them. This of course requires that the key that creates those is not residing on the websites server (i assume hydra and other infra is segmented). Managing a root-of-trust is probably non-trivial, like having a root key distributed among the board members via Shamir Secret Sharing or similar from which then leaf keys are crated to be used for signing ISO’s and other tasks that benefit from it.
Problem is that NixOS ISOs on the download page are uploaded automatically when the channel updates. So to do GPG signing of ISOs, either:
- We have to change to maintainers manually building, signing, and uploading
- We have to make signing meaningless by automating it
- We have to make signing meaningless by making it a semi-automated routine with minimal manual effort (and therefore minimal verification) from maintainers.
1 Like
It depends on the threat model. In case of a full breach of our infrastructure a automated signature is indeed meaningless. A automated signature would prevent tempering as-long as the builders integrity isn’t compromised. Effectively providing a proof that the images are created by our CI.
in theory you can already get that by checking the nix signature from cache.nixos.org for the ISO, though yea that’s not linked on the download page
I find that to be overkill when the ISO download is already authenticated via TLS.
Yeah, but the private keys for that are outside “our” servers, distributed over the whole world… so I can see that it’s not ideal from a strict point of view.
1 Like
I’m very new to the community, but I hope this is a helpful addition and not an annoying necro; I found that chaining the ipxe from https://github.com/nix-community/nixos-images/releases/download/nixos-24.11/netboot-x86_64-linux.ipxe worked very well in my case for getting NixOS running without needing to download and burn an ISO.
Maybe an iPXE/netboot section can be added to the download page, rather than it solely being a footnote at Netboot - NixOS Wiki, which is how I found it. If a user has a bootloader already, setting up the kernel and initrd in their boot partition would be a straightforward way to use NixOS.
Basically and in summary, my idea is, if isos are not the ideal way to get started with NixOS, and I would agree that they’re probably not, would advertising the kernel and initrd and providing instructions for grub/syslinux/ipxe be an alternative?
Maybe I misunderstood you, but almost noone really burns the ISOs nowadays. You simply dd them to an USB stick.
1 Like
I meant more metaphorically burning, it takes time to write an ISO to a usb, I’ve found netboot to be much more convenient
2 Likes
Not really. In a normal NixOS installation, the boot loader is configured with one entry per generation, and each generation points to its kernel and initrd, and provides a mostly-unique init= kernel param that’s used by initrd to find the generation on the root fs to boot into. Two different generations may use the same kernel and initrd, or they may use different ones, but they will almost certainly use different init= params to indicate the specific configuration. So you can’t just plunk a kernel and an initrd onto a boot partition and point a boot loader at them. You have to know what the /nix/store/.... path on the root fs representing the generation you want to boot is and provide that as a kernel param.
1 Like
The generated ipxe already does this:
#!ipxe
# Use the cmdline variable to allow the user to specify custom kernel params
# when chainloading this script from other iPXE scripts like netboot.xyz
kernel https://github.com/nix-community/nixos-images/releases/download/nixos-24.11/bzImage-x86_64-linux init=/nix/store/gqg5692q8cica6dyaki9ak0pf8qf0kpj-nixos-system-nixos-24.11beta708350.1d95cb5/init initrd=initrd-x86_64-linux nohibernate loglevel=4 ${cmdline}
initrd https://github.com/nix-community/nixos-images/releases/download/nixos-24.11/initrd-x86_64-linux
boot
Right, I’m just saying that it’s not as simple as putting a kernel and initrd on a boot partition. The ipxe stuff itself is very different from that.