The LiveUSB is people's first impression

Development Documentation
1

I’ve been meaning to try out nixos for a while, the concept is great but the live usb is the first impression people get. Here’s what happened.

  • Downloaded an dd’d the liveusb from the website. Grabbed the plasma one as I prefer plasma to gnome: nixos-plasma6-24.05.1695.dd457de7e08c-x86_64-linux.iso
  • Rebooted. Nixos (or the drive its on) doesn’t appear in the UEFI boot options
  • Boot back into Arch and check that the usb looks right (it does)
  • Rebooted back into bios. Enabled CSM mode (Why is this necessary in 2024?)
  • Rebooted back into BIOS.
  • Selected the drive containing NixOS to boot from
  • Saw Grub (Yay it’s working!)
  • Selected the live installer. Black screen.
  • Waited 3 minutes. Black screen.
  • Switched TTY. Nothing.
  • Rebooted, select nomodeset (again, shouldn’t be necessary)
  • It booted into a terminal and said to start the display-manager service. Nothing.
  • Ran systemctl status display-manager it just said failed to start.

Not a great first experience, failed at the most basic task, displaying the installer on the liveusb :frowning:

My hardware isn’t very exotic and 18 months old (7950x, 7900xtx) so nothing that should require a bleeding edge kernel.

2

It isn’t. The installer is very much supposed to work with UEFI.

I have the same CPU and nearly the same GPU (7900 XT) and the plasma6 installer booted without issue for me, both with UEFI boot and without nomodeset. I did not try booting with CSM at all, because, as I said, that’s not necessary.

Are you sure the ISO was written successfully? Did you make sure to sync the drive before rebooting?

3

I’m not sure why, but it was something to do with the USB stick I was using, tried another and it worked fine.

I think the black screen was something to do with not booting in UEFI mode as well.

4

I recommend using Ventoy to avoid dd-ing your USB drives into oblivion :grin:

5

I strongly recommend against ventoy for multiple reasons.

  1. It ships an embedded OS’s worth of prebuilt binaries that it does not build from source, and AFAICT nixpkgs still packages it that way.
  2. The way it actually works is by committing unspeakable crimes against early boot that I’m shocked work at all.
  3. And in fact, it doesn’t work reliably. It’s very common for it to simply not work with NixOS.
5 Likes
6

Still, dd is unnecessary, using cp should be just fine, and faster to get going.

7

dd does some useful things, though you have to add them on the command line, mainly around syncing. I have

alias sdd="sudo dd bs=8M oflag=sync,direct conv=fsync status=progress"

status=progress shows the progress but it’s pretty misleading because it’ll do async writes and return basically instantly. conv=fsync ensures all the writes have been sync’d before the command returns (which cp does not do), but progress still appears to progress too quickly until it stalls at the end. oflag=sync,direct finally fixes the progress indicator by having every write be synchronous. bs=8M is just what I’ve found to be a very fast blocksize for most flash drives.

4 Likes
8

after seeing your talk at nixcon, I’d think you’d find that fascinating :rofl:

9

it is, but like in a bad way :stuck_out_tongue:

1 Like