I have a 64 GB USB flash drive. I can easily dd a NixOS ISO onto it to make it bootable and install NixOS on a fresh machine, but I want to use the excess space on the flash drive to store important files (e.g. a config, some keys).
This thread doesn’t seem to have a solution.
I’ve tried partitioning it and writing the ISO onto the first partition, but that doesn’t work. Any ideas?
Try something like Ventoy or netboot.xyz.
Thank you! For some reason, I always thought Ventoy just provided a GUI to write the ISO to the drive (equivalent to a dd) but it evidently does a lot more.
(Please don’t recommend ventoy. Reasons: The LiveUSB is people's first impression - #5 by ElvishJerricco)
Yea, the ISO has to use a very strange format in order to work on the maximum range of possible media. Unfortunately we don’t really have a way to do this any differently right now. You could create custom images (note: different from a custom ISO), but this gets kinda complicated.
Huh, interesting. I’ve been using Ventoy for years without issues, including booting NixOS for the past year and a half.
However, I will cease recommending it and go investigate other multi boot solutions when I get a chance!
@ElvishJerricco Interesting, thanks for the link! I don’t understand disk images at all and know effectively nothing about the boot process. Do you know of any place where this procedure is documented?
All I want is one bootable partition (or whatever is required to have a NixOS live ISO) and the rest as a writable filesystem (e.g. ext4). It feels like this should be a very common well-solved problem but apparently not. 
Yea the ISO really isn’t designed for that right now. The section of the nixos manual that I linked in my last comment is the official documentation for creating images, but it’s a little barebones and only really provides a basic example of getting a nixos image built, and not a very well optimized one for something like a USB drive (e.g. I’d use an erofs for the store just to make it perform better on slow USB sticks).
@ElvishJerricco Do you think the referenced repart.nix module would allow me to do what I want? If so, I’ll try and tinker with it. I’m already building a custom ISO, might as well create a custom image too.
Yeah. The issue is that the shenanigans necessary to get an ISO image on the usb stick recognised as a device are incompatible with additional partitioning, and the shenanigans necessary to just use an ISO file in a separate filesystem (that would allow further partitioning) are either ventoy or highly system specific.
In both cases, it’s the fact that you’re trying to emulate a cdrom disk image that leads to the restrictions of seeing the rest of the device.
The disk image stuff is different; ignore the ‘image’ part of that to begin with, in case that sounds too similar to an iso image. What you’re doing instead is creating a bootable live usb installation, using partitions and filesystem on the usb stick. You could install that manually, and boot it every so often to self-update.
The custom image method is a way of preparing an image separately on an existing running machine, in the store as a file, that you can write to the usb stick and then use. Same result, much more declarative process.
I think I understand. So by fiddling with repart.nix, I’ll be able to create an object in the nix store, which when written to the USB drive (dd?), will have the magic combination of partitions/filesystems/whatever to provide a bootable live USB and also usable space.
This isn’t an “ISO” file that’s being written, because that has some (archaic) cdrom-based format that would mess up using the rest of the disk. But such a format is what’s used by default by NixOS to maximize compatibility.
exactly that. the .iso is a cd (/dvd) image, containing an iso9660 or UDF filesystem, that also happens to work when dd’d to a usb stick (with a small amount of bios emulation help). cd’s don’t really support partitioning.
the image you can make with that repart reference is a normal system closure (see the storePaths = [ config.system.build.toplevel ]; bit) and some filesystems and disk layout. You can put whatever filesystems you like in there. I might be tempted to try f2fs, though it’s not one of those listed and it’s not 100% clear to me whether that list is exhaustive.