I have been trying to get NixOS 14.12 on my computer where I'm currently running Arch Linux. It is an older Apple tower, with a GeForce 8800 GT video card.
I first tried the graphical live CD. It boots, gets to grub, then says "error: no suitable video mode found. Booting in blind mode."
I gave up on the graphical live CD and tried the minimal CD instead. Similarly, the grub menu displays and then tries to boot the kernel. But this time I just get a blank screen.
I was booting from a USB key and tried creating it with both unetbootin and doing the "alternative" grub install described on the USB install page. I also tried blacklisting the nouveau with modprobe.blacklist=nouveau
. I tried other variations like nouvea.blacklist=1
and nomodeset
after googling for similar issues. Nothing seemed to improved the situation.
At this point, I'm stuck.
Can you try 15.09 image? http://nixos.org/releases/nixos/15.09/nixos-15.09.453.dc18f39/
@domenkozar Very little change. I no longer see the message, "error: no suitable video mode found. Booting in blind mode." But after the boot menu I am still left with a blank screen, with both the graphical and minimal ISOs, whether I blacklist nouveau or not.
IIRC we now blacklist nouveau and have nomodeset by default on ISOs.
I came back to this today and tried a few different things. Finally, I tried setting up the LiveCD in my existing Arch Linux install with grub as described here. Following those directions I was able to boot into the LiveCD.
I'm going to attempt an installation and see what happens.
The installation completed and I chose gummiboot as the boot loader, but the same thing happens. After choosing the latest NixOS generation, the screen blanks and nothing more happpens.
I tested with the Arch and Ubuntu LiveCDs and they both work, so I think that eliminates a problem with the system itself.
Same problem here. Minimal USB install of 15.09, I choose "Live CD", and immediately just get a black screen. Motherboard is ASRock Z68 Pro3 Gen3, and I've removed my video card. Let me know if there's any more detail I can provide. I have no idea what to try now.
Also tested with the graphical install of unstable, got the same result.
This sounds like modesetting gone awry. Try adding:
nomodeset i915.modeset=0 nouveau.modeset=0
To the kernel command line before exiting grub.
(source https://wiki.archlinux.org/index.php/Kernel_mode_setting)
@jcumming How do I do that? All I get to is a screen that says "NixOS Live CD". Is that grub?
Ah, it's gummiboot, and the key is "e" to edit the command.
Didn't help, though :(
I believe nomodeset is passed on ISOs by default (which disables nouveau completely).
@vcunat nomodeset
is set by default, though that arch page says
For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. "
nomodeset i915.modeset=0 nouveau.modeset=0
").
The next step I would use is a serial console.
Is that hardware that people normally keep around?
Serial ports aren't so common on consumer hardware these days. However, if the kernel is running you can probably use a USB serial dongle and concoct a grub command line to get the kernel and systemd to issue a console on it.
Video problems are difficult to debug -- you're blind to whatever the kernel is telling you. And it can be telling you a lot of things about hardware conflicts, BIOS bugs, missing drivers, etc.
Is there a way to get it to log to the boot media (a USB drive) or elsewhere?
(triage) Is this still an issue?
I was able to get a working system using the NixOS unstable branch and using the latest kernel by specifying linuxPackages = pkgs.linuxPackages_latest;
as a package override. I'm ok with closing this issue at this point.
cc @vcunat
Yes, this is still an issue.
@purefn
by specifying
linuxPackages = pkgs.linuxPackages_latest;
as a package override
Can you clarify what this means? Where did you specify that?
I assume you mean it's still an issue with 16.09 or unstable image.
Yeah, 16.09 is what I've tried.
@chris-martin I can't give suggestions on how to fix it, but I have some ideas on how to debug it:
Sorry this is so painful, but without a serial console I can't think of many other options to even figure out what's wrong, let alone fix it. Others might have better ideas...
Have the same problem: absolutely black screen after gummiboot, but boots OK if UEFI is off.
Tried NixOS 16.09 and 17.03, graphical and minimal via USB flash dongle labeled NIXOS_ISO created with dd
or rufus.
Tried different options:
loglevel=7 nomodeset systemd.unit=rescue.target debug acpi=0 acpi_osi=linux acpi_backlight=vendor noalpic i915.i915_enable_rc6=1 i915.modeset=0 radeon.modeset=0 nouveau.modeset=0 pci=nocrs modprobe.blacklist=nouveau
.
Similar problem in Ubuntu (turning off NIC in BIOS helped). Didn't help me.
Will it be possible to boot in lagacy BIOS mode, install NixOS and then switch back to UEFI?
@ilyaigpetrov: yes, certainly. EDIT: that doesn't guarantee it will boot in UEFI mode; I just don't know.
Use the NixOS image building scripts (on a working linux) to make yourself a bootable USB stick with a config that mostly matches the one we use on the bootable CD. I can go into more detail here if needed, even though I haven't done it myself.
I'd love to know how that works.
Actually (offtopic), it'd be really cool if building a custom ISO was the recommended way to install.
I'm actually trying (in baby steps) to improve the image building processes as we speak/write (fixing up a PR I made to speed it up significantly in virtualized environments) 😄
I think the key parts you'll want are this page which should (I haven't tested it) let you just dd your image onto a USB stick (or if that doesn't work, that unetbootin part probably will). To get the iso file, this page should do the trick. Once you have it building an ISO from a configuration of your choice, I'd probably enable rsyslog in and configure it to dump kernel messages to a file on the USB stick, http://unix.stackexchange.com/a/89229. Then just build the ISO, dd
it to your USB stick, let it boot, and when you get a blank screen, check the log file on the stick from another machine.
I obviously haven't tested any of this but I don't see why it shouldn't work with some massaging. You'll probably need some filesystem config to get it to mount the usb stick RW after booting at a mount point you know.
This is what I tried (attempt to compile iso with rsyslog):
netconsoe
-- doesn't work, it is just ignoredgit clone --depth 1 -b release-17.09 --single-branch https://github.com/NixOS/nixpkgs.git
of r17.09nixpkgs/nixos/modules/services/logging/rsyslogd.nix
according to unix89229environment.systemPackages = [ ...bla... pkgs.rsyslog ];
to nixpkgs/nixos/modules/installer/cd-dvd/iso-image.nix
(dd
ed minimal iso of 16.09 to 16GB usbmount -o remount,size=16g /nix/.rw-store
cd nixpkgs
export NIXPKGS=`pwd`
export NIX_PATH=$NIXPKGS
nix-build -A iso_minimal.x86_64-linux $NIXPKGS/nixos/release.nix
[root@nixos:/foo/nixpkgs]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 151M 0 151M 0% /dev
tmpfs 1.5G 0 1.5G 0% /dev/shm
tmpfs 753M 4.3M 749M 1% /run
tmpfs 16G 217M 16G 2% /
/dev/root 15G 711M 15G 5% /iso
/dev/loop0 684M 684M 0 100% /nix/.ro-store
tmpfs 16G 1.7G 15G 11% /nix/.rw-store
unionfs 17G 2.4G 15G 15% /nix/store
tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup
tmpfs 301M 4.0K 301M 1% /run/user/0
/dev/sda4 98G 13G 85G 13% /mnt
# Copypasted from 16.09 (tag), not release-16.09, but I checked both -- both fail.
gzipping man pages in /nix/store/s0wng1rn5pnddrigjjqszxc5bip4j46i-perl-5.22.2-devdoc
invalid ownership on file ‘/nix/store/qj1p9cdc9h4fhcz75qvk49azzq3gx4y0-perl-5.22.2/bin/perlbug’
cannot build derivation ‘/nix/store/fa3aq45swqqfy8zi3gmpxnzdzji7w0hl-bison-3.0.4.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/ddsgnsq8d88mimgd70fwf4jl2irhnd73-coreutils-8.25.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/0bcg71vhqhbq0vif5n8r93va64l8i3bl-gcc-5.4.0.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/sncl9d5v8sc5djgmpr8h7mhydz0nkyrh-gnugrep-2.25.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/53yh4wyxak4sg2j332zz4fghsg75nsn3-linux-headers-4.4.10.drv’: 1 dependencies couldn't be built
building path(s) ‘/nix/store/0djw49xzsqz9a78wl1girvx0vfmcymmm-zlib-1.2.8-static’, ‘/nix/store/2mrgjcvnmy1ha159dj1kpkq3dsxnd3pn-zlib-1.2.8’, ‘/nix/store/gxiaswl0bqnkwi8zjw56bc6k7fdh27p9-zlib-1.2.8-d
ev’
cannot build derivation ‘/nix/store/89ck7bahzlpvh8gv5vw79h7lc0d5ym08-bash-4.3-p46.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/sxfhzzdzxzx5f5w6w1ap41ibxl7vd90i-binutils-2.27.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/v4992m7w9vl2xhbg1ppbvxj9yhrniyy0-gcc-wrapper-5.4.0.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/9bpv45fh9i81zdgv65rv9yanhwdh5a2s-glibc-2.24.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/y305ppd5vrg2ij15cawy15fqca952czi-kmod-blacklist-3ubuntu1.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/dq686ia2vdziripk7vv299c125j3s4z5-lvm2-2.02.140.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/h5x35kjs05wpk69aaivn8dgsiwwys894-nixos-system-nixos-16.09beta-33749.gfedcba.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/jg600k05h91n26b7k6paz16rwrb5z5an-perl-5.22.2.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/68qb6k9ns9dj5q99vczyrzkipv9zb61r-sharutils-4.11.1.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/ljrm56h1sb6m9m7rqv84yv60x10byjl0-spl-kernel-0.6.5.8-4.4.23.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/0sk8c3s57bdj4y9n9a5f7zng7fbhx1zj-stdenv.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/lwh6b1dk729maxi00xjclmha1gcwp2qa-stdenv.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/r37wlc8f4cibbpv9q6hl96vby4pdvq84-systemd-231.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/6fkshyj9dxxs9jq3gn12p8jhiwzk7b9a-zfs-kernel-0.6.5.8-4.4.23.drv’: 1 dependencies couldn't be built
cannot build derivation ‘/nix/store/94xqk0qh6b6kxbhd5hizw4rr5jpdfbn4-nixos-minimal-16.09beta-33749.gfedcba-x86_64-linux.iso.drv’: 1 dependencies couldn't be built
error: build of ‘/nix/store/94xqk0qh6b6kxbhd5hizw4rr5jpdfbn4-nixos-minimal-16.09beta-33749.gfedcba-x86_64-linux.iso.drv’ failed
I have little time for resolving this error now, so I just dump it here.
Any solutions are welcomed.
__UPD__:
I was trying to compile iso from a nixos booted from usb. Later I figured out that you don't need nixos for this, but you just need a nix package manager, which you may install on your system by following https://nixos.org/nix/download.html
Currently experiencing this issue on several machines, all Mac hardware.
I've tried dd
'ing to several different disks, and also attempted the syslinux method documented here.
Each attempt results in the same issue: I get the bootloader, but upon attempting to boot either the standard config, or nomodeset, or any of the debug kernel options, it instantly goes to a black screen.
One thing I've noticed is that the LED indicator on the USB devices I have tried that indicates I/O glows solid as soon as I select a menu entry, which would imply no data is attempting to be read from the disk. That said... I'm not sure how useful that information is. I figure it could imply a kernel failure, rather than simply a graphical failure.
Wondering how I can debug this further. I've spoken with someone on the #nixos IRC channel who's successfully booted and installed NixOS on the exact same MacBook Air model I've been attempting this on (also observed this issue on other systems, too).
Thanks in advance for any advice on this.
EDIT: I should also mention I'm trying this with the current release of NixOS (17.03), but the same behaviour is observed with all previous install media still available (15/16,etc.)
@cmacrae You should try building nixos iso with rsyslog configured to log into a file. Try repeating my steps in my post above (starting from point 2). As I fail to compile it on my system it would be great if someone else compile it and share with us so we can record logs.
@ilyaigpetrov Good point! I'd be more than happy to do so - I have a working NixOS installation on another system. It's not very powerful... so could take some time, but I'll happily try this and report back.
Is the main aim here to build an ISO that has rsyslog dumping kernel messages to a file on the USB install medium?
I was able to build an ISO with the rsyslog modifications in successfully and boot it.
Though... I'm now having trouble finding the file that rsyslog wrote, haha.
I set an entry in the rsyslog config to send kernel messages to /var/log/kernel-messages
, I've mounted the install USB back on another machine after attempting to boot, but I'm unable to find the kernel-messages
file.
@cmacrae: IIRC the standard FS setup is that the iso contents is mounted read-only with a writeable "overlay" FS that has no backing device, so changes aren't persisted anywhere by default.
Cheers @vcunat - I'll have to figure out how I can mount some writable storage. Any pointers?
On another note: these rsyslog settings (the inclusion of the package and the configuration); I'm wondering if they alone will be enough to retrieve the debugging information. Moreover: is there anywhere I need to configure rsyslog's invokation? Obviously this is very early on in init (I presume) that the failure is happening. So I'm not sure if rsyslog is even going to be alive at that point - I'm used to interacting with it as a daemon. Are there any directives in the boot process that ensure such configurations will be adhered to, and thus produce the needed output?
Maybe add an extra entry into boot.specialFilesystems
and log into a completely separate partition, but I've never tried anything like that. I've seen some people praising the serial console for such debugging (stuff being logged into the cable and read from outside).
@vcunat Alright, cheers. I'll take a look at boot.specialFilesystems
:+1:
Regarding the serial console: the restrictive part here is hardware. I'm not sure it'd be viable on this set-up.
That said, I do actually have a USB to DB9 serial adapter, and I even have an old VT220 terminal I could hook it up to. Just not sure if it'd see the USB interface as a serial port. Perhaps this is something I could look into.
@vcunat Can @cmacrae just take his already compiled iso and modify /etc/fstab
converting read-only mounts to read-write mounts?
squashfs isn't a writable filesystem, I think.
Well, a USB serial adapter -> terminal definitely isn't an option. It was overly optimistic for me to assume that syslinux (or any bootloader, for that matter) would have a USB stack implemented...
overly optimistic to assume that syslinux (or any bootloader, for that matter) would have a USB stack implemented...
Oh well, GRUB2 _does_ have some USB-serial terminal support.
Maybe there is also some UEFI-assisted option, too…
Yeah, I'm at a bit of a loss right now. Not sure how to approach the syslog method.
It's really just very strange that this is happening at all: I'm able to boot other Linux distros in the exact same manner without an issue on all the machines I've tried (all Macs).
I was previously running Void Linux on my MacBook Air (before wiping it in prep for NixOS install), and that performed great. Just very curious as to what the issue is.
The hardware I've been attempting to boot on varies quite a bit in terms of years.
The MacBook Air is from 2011, the iMac is from 2015, the Mac Mini from 2014.
So, I was actually able to boot NixOS on my work MacBook Pro (early 2015 model) last night, with absolutely no tweaks necessary.
Great news for me, as I want to run NixOS as my daily driver OS for work - just unfortunate the story isn't the same for my personal machines.
I'm installing NixOS on a new machine today. Lessons learned:
boot.kernelParams = [ "nomodeset" ];
to the config.That isn't a solution on my other computer, but it seems to fix the same problem on the new one.
Although, I don't know if this is related: If I leave the machine while without pressing any keys, the screen blanks and I have to reboot.
I'm having the same issue here, installed debian instead. Is there anything I can do to help?
It would be great if someone experienced provided a step-by-step guide on how to compile iso with boot.specialFilesystems
configured right for rsyslog (or other tool like systemd) so we all could retrieve some logs from our machines and troubleshoot it further.
Just out of curiosity. My notebook doesn't have serial port, so it's unlikely I could use serial console. Is it possible to look for [UART] connectors on motherboard and attach serial console to them somehow?
Yes, should be. Or attach usb-serial dongle.
Related to perl build issue (seems to be caused by unionfs) - https://github.com/NixOS/nix/issues/1243
I wanted to report that I've successfully installed NixOS on a Macbook Air (late 2011), which previously had the same issue. That wasn't easy: I booted an Ubuntu live cd, then followed @chris-martin 's excellent guide to install NixOS from there (https://gist.github.com/chris-martin/4ead9b0acbd2e3ce084576ee06961000).
My first attempt had the exact same result: I saw the system-boot menu, and then a blank screen.
Then I tried again, this time setting Grub2 as the boot loader (and disabling systemd-loader). It worked!
I suggest switching to Grub2 for the installation CD. Not sure how to do it though.
When I boot NixOS 17.09 or 18.03 live images in UEFI mode in VMWare Workstation 14 under Windows 10 the screen turns black while booting. Maybe other environments are affected too, I don't know, that's just the setup I have to work with. BIOS mode or other distros in UEFI mode work fine tough.
The last log message I can see is running udev...
, but the system seems to boot correctly nevertheless, e.g. when I wait a few seconds, blindly type poweroff
and hit enter the vm shuts down.
The recommendation to add nomodeset
to the kernel parameters fixed it.
Still an issue for nixos-graphical-18.09pre149415.8395f9aa85e-x86_64-linux.iso.
I appreciate @P-E-Meunier's revelation that grub2 may fix the issue, though haven't tried it myself.
Oh, uh well, @P-E-Meunier , @ilyaigpetrov I have #33686 which (in this case coincidentally) changes the UEFI bootloader to grub.
Could any of you having the issue try with an installer image built from that PR and report back?
(It's going to be merged anyway for 18.09 I'm pretty confident, but having such a report could be useful to track another pro for switching to grub.)
EDIT: pinged the wrong ilya*
.
@samueldr: if you point me to the instructions to do so I can try.
♥ thanks for volunteering for the test.
The instructions are just now added to a comment; I additionally have rebased on the latest nixos-unstable. The iso image is used like any other nixos iso image, which is why I haven't added dd
instructions.
I've found a workaround:
1) Get graphical iso (nixos-graphical-18.03.133157.fde20125199, e.g.).
2) Boot the default entry from the menu.
3) Get your black screen and give it time to load. The idea is that there is no error, NixOS is loading, you are just blind (thanks @BenKerry ). USB pen drive with R/W-indicator is helpful here.
4) After some time blindly enter command: systemctl start display-manager
and give it some time again.
5) If you are lucky you will get KDE Plasma shell, otherwise hit enter and try repeating the previous command.
You should be able to install NixOS from this shell, but I'm not sure if it will boot.
By making the graphical image always boot to the display-manager, or by adding an option to the bootloader enabling/disabling the display-manager by default could allow working around this issue. (Noting this here, for a future improvement.)
Just wanted to drop a message here saying I am trying NixOS for the first time in VMWare and could not get the minimal CD to boot. I found this reddit post with a link to here, and those options worked. Not a great experience for a newcomer.
I hit this when trying to install nixOS 18.09 on a NUC8i7. What worked for me was to try a newer kernel (4.19.9, which i got here) and boot _with_ modeset, i.e. not using the nomodeset
option. Hypothesis: GRUB seems to leave the video card in a bad state, but once the i915 driver kicks in it fixes things up.
I saw this in dmesg
which looks suspicious:
efifb: invalid framebuffer address
It shows up with or without nomodeset
, but when nomodeset
is present on the command line, the video card never properly boots up and it stays on black screen forever. Without nomodeset
, the screen goes black immediately after pressing Enter on the GRUB screen, but starts showing things after about 10 seconds.
This launchpad bug might be relevant? https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1785033
Note: once nixos is actually installed, there don't seem to be any issues. Must be just an issue with the livecd.
NB: if you try this method, make sure you use linuxPackages_latest when you install!
One more data point: I tried to install NixOS on a Dell Inspiron 9571 for a very long time. I switched from RAID to AHCI and disabled secure boot, but neither were good enough.
First I tried with the graphical live cd, and was unable to get past grub, even with nomodeset
, debug
, and acpi=off
, as well as different combinations of them - no errors or anything, it just would not work. Next, I tried with the minimal installer - no dice. Combinations of nomodeset
, debug
, acpi=off
didn't help either.
After all of this, I tried using the gist posted above to install using Ubuntu (very good stuff, aside from a few mistakes). I was surprised that Ubuntu's live CD worked out of the box, while nix's didn't.
I am also getting a black screen as soon as I log in to NixOS KDE. And based on messages above it might be related to UEFI boot used inside VirtualBox.
I am getting the same black screen after login when I am using GRUB (BIOS) boot.
This is how the black screen issue manifests itself:
The solution was to disable 3D acceleration.
I marked this as stale due to inactivity. → More info
Most helpful comment
When I boot NixOS 17.09 or 18.03 live images in UEFI mode in VMWare Workstation 14 under Windows 10 the screen turns black while booting. Maybe other environments are affected too, I don't know, that's just the setup I have to work with. BIOS mode or other distros in UEFI mode work fine tough.
The last log message I can see is
running udev...
, but the system seems to boot correctly nevertheless, e.g. when I wait a few seconds, blindly typepoweroff
and hit enter the vm shuts down.The recommendation to add
nomodeset
to the kernel parameters fixed it.