Possibly more NVIDIA trouble

I am experiencing what I believe could be some trouble with NVIDIA and booting on NixOS 23.05. I am running open source NVIDIA drivers and have also tried their proprietary ones. I do also have home-manger and flakes enabled, but I don’t have anything running in either the home-manager standalone or in any flakes that should affect the booting process.

Problem:
When I boot up, I am greeted by systemd-boot, then Plymouth and my luks password prompt. That all seems to be working okay. I have sddm setup to autoLogin to my user and then load up Hyprland, which means I’m also using Wayland and Xwayland. Half of the time, everything seems to login just fine, but the other half of the time I see my system get hung up and I have to wait for some startup process to finish, and then I am able to login using TTY and reboot. This is obviously not ideal, so I would like to figure out what I may have broken.

What I expect:
I expect it to boot straight in to Hyprland after luks all of the time.

Here are some of the relevant parts of my config which might help figure out what’s going on. I’m fairly new to NixOS and especially with dealing with issues during boot, so I would really appreciate any pointers or help you may have. Thank you.

 boot.loader.systemd-boot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;
  boot.initrd.systemd.enable = true;
  boot.kernelParams = ["quiet" "nosgx"];
  # for Plymouth
  boot.plymouth = {
    enable = true;
    theme = "hexagon_red";
    themePackages = [(pkgs.adi1090x-plymouth-themes.override {selected_themes = ["hexagon_red"];})];
  };

  # OpenGL
  hardware.opengl = {
    enable = true;
    driSupport = true;
    driSupport32Bit = true;
  };
  
  # NVIDIA Settings
  hardware.nvidia = {
    modesetting.enable = true;
    open = true;
    nvidiaSettings = true;
    package = config.boot.kernelPackages.nvidiaPackages.stable;
  };

  # Enable NTFS support
  boot.supportedFilesystems = [ "ntfs" ];
  fileSystems."/mnt/extra" = {
    device = "/dev/sda";
    fsType = "ntfs-3g";
    options = [ "rwx" "uid = 1000" ];
  };

# Hyprland
  programs.hyprland.enable = true;
  programs.hyprland.xwayland.enable = true;
  programs.hyprland.nvidiaPatches = true;
  environment.sessionVariables.WLR_NO_HARDWARE_CURSORS = "1";
  
  xdg.portal = {
    enable = true;
    wlr.enable = true;
    extraPortals = with pkgs; [
      xdg-desktop-portal-gtk
      xdg-desktop-portal-wlr
      xdg-desktop-portal-hyprland
    ];
  };

  # X Server
  services.xserver = {
    enable = true;
    layout = "us";
    xkbVariant = "";
    videoDrivers = [ "nvidia" ];
    displayManager = {
      sddm.enable = true;
      autoLogin.enable = true;
      autoLogin.user = "CipherJay";
      gdm = {
        enable = false;
        wayland = false;
      };
    };
  };

  programs.xwayland.enable = true;

Why does everyone do this? They’re explicitly marked as beta by nvidia and not ready for a daily driver. They don’t even do anything better than the proprietary driver, they’re effectively just a partial source dump of their third party kernel module that’s been duct-taped into some kind of functionality, taking over all the same issues you have with the proprietary one and adding some fresh, new “beta” issues.

There won’t be a proper nvidia driver until the canonical folks finish NVK, and even that will come with limitations.

Can you get logs from one of those failed boots with journalctl --boot -1 or such?

Hm, you’re missing most of the settings recommended by the nvidia wiki page, have you seen it? https://wiki.hyprland.org/Nvidia/#how-to-get-hyprland-to-possibly-work-on-nvidia

1 Like

Thank you for letting me know. I was going off of what someone told me, but he obviously didn’t know what he was talking about.

I went ahead and added these extra session variables and switched to the proprietary driver. I read this page too, but I completely forgot about it when switching over from Fedora. Thank you for pointing this out. It appears like things are running smoothly now, except my auto login script doesn’t seem to work now. I can, however launch Hyprland from the TTY just fine, which is what’s important.

I went back to my last failed boot and found these errors in my journalctl (three boots back). Here’s what I found:

kernel: nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
kernel: ucsi_ccg 0-0008: i2c_transfer failed -110
kernel: ucsi_ccg 0-0008: ucsi_ccg_init failed - -110
kernel: ucsi_ccg: probe of 0-0008 failed with error -110

bluetoothd[1081]: profiles/audio/vcp.c:vcp_init() D-Bus experimental not enabled
bluetoothd[1081]: src/plugin.c:plugin_init() Failed to init vcp plugin
bluetoothd[1081]: profiles/audio/mcp.c:mcp_init() D-Bus experimental not enabled
bluetoothd[1081]: src/plugin.c:plugin_init() Failed to init mcp plugin
bluetoothd[1081]: profiles/audio/bap.c:bap_init() D-Bus experimental not enabled
bluetoothd[1081]: src/plugin.c:plugin_init() Failed to init bap plugin
bluetoothd[1081]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
bluetoothd[1081]: sap-server: Operation not permitted (1)

login[1384]: gkr-pam: unable to locate daemon control file

kernel: watchdog: watchdog0: watchdog did not stop!

I selected all of the errors and warnings I found. This is my first time asking for help like this, so I hope I gave enough information. I have never had to look at kernel errors before, so thank you very much for your help with this. As a noob I may be in over my head with NixOS, but I figured it would force me to learn how to swim.

I removed my .zprofile script, then rebooted and it hung on Plymouth for a while and then let me access root. I then tried to boot Hyprland from my user using zsh as I had before and it core dumped. I tried it two times and then reboot. On my next boot it just auto logged in like it had done before. I have no idea why, but this makes me realize my .zprofile script isn’t doing anything.

These are the errors I found in my journalctl for this previous boot that core dumped when attempting to launch Hyprland from the TTY:

Aug 01 18:22:34 localhost systemd-tty-ask-password-agent[309]: Failed to send: No such file or directory
Aug 01 18:22:34 localhost systemd-tty-ask-password-agent[309]: Invalid password file /run/systemd/ask-password/ask.WSlnDj
Aug 01 18:22:34 localhost systemd-tty-ask-password-agent[309]: Failed to process password: No such file or directory

Aug 01 18:22:39 nixos kernel: ucsi_ccg 0-0008: failed to get FW build information

Aug 01 18:22:40 nixos kernel: nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
Aug 01 18:22:40 nixos kernel: ucsi_ccg 0-0008: i2c_transfer failed -110
Aug 01 18:22:40 nixos kernel: ucsi_ccg 0-0008: ucsi_ccg_init failed - -110

Aug 01 18:24:08 nixos systemd[1]: dev-sda.device: Job dev-sda.device/start timed out.
Aug 01 18:24:08 nixos systemd[1]: Timed out waiting for device /dev/sda.
Aug 01 18:24:08 nixos systemd[1]: Dependency failed for /mnt/extra.
Aug 01 18:24:08 nixos systemd[1]: Dependency failed for Local File Systems.

Aug 01 18:24:08 nixos (plymouth)[1138]: emergency.service: Executable /nix/store/rpagyb9792jx4f2hlqz9q0ld3frlzxq5-systemd-253.6/bin/plymouth missing, s>
Aug 01 18:24:10 nixos systemd[1]: Created slice Slice /system/systemd-coredump.
Aug 01 18:24:10 nixos systemd[1]: Started Process Core Dump (PID 1191/UID 0).
Aug 01 18:24:10 nixos systemd-coredump[1192]: Resource limits disable core dumping for process 267 (plymouthd).
Aug 01 18:24:10 nixos systemd-coredump[1192]: [🡕] Process 267 (plymouthd) of user 0 dumped core.
Aug 01 18:24:10 nixos systemd[1]: systemd-coredump@0-1191-0.service: Deactivated successfully.
Aug 01 18:24:10 nixos systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=11/SEGV
Aug 01 18:24:10 nixos systemd[1]: plymouth-start.service: Failed with result 'core-dump'.
Aug 01 18:24:10 nixos systemd[1]: plymouth-start.service: Consumed 4.842s CPU time, no IP traffic.
Aug 01 18:24:49 nixos su[1202]: Successful su for CipherJay by root
Aug 01 18:24:49 nixos su[1202]: pam_unix(su:session): session opened for user CipherJay(uid=1000) by (uid=0)
Aug 01 18:24:53 nixos systemd[1]: Started Process Core Dump (PID 1402/UID 0).
Aug 01 18:24:53 nixos systemd-coredump[1403]: [🡕] Process 1401 (Hyprland) of user 1000 dumped core.

                                                  Module libpcre.so.1 without build-id.
                                                  Module libbrotlicommon.so.1 without build-id.
                                                  Module libgraphite2.so.3 without build-id.
                                                  Module libdatrie.so.1 without build-id.
                                                  Module libselinux.so.1 without build-id.
                                                  Module libpcre2-8.so.0 without build-id.
                                                  Module libgpg-error.so.0 without build-id.
                                                  Module libgudev-1.0.so.0 without build-id.
                                                  Module libbrotlidec.so.1 without build-id.
                                                  Module libbz2.so.1 without build-id.
                                                  Module libexpat.so.1 without build-id.
Aug 01 18:24:08 nixos systemd[1]: Received SIGRTMIN+20 from PID 267 (plymouthd).
Aug 01 18:24:08 nixos systemd[1]: Finished Tell Plymouth To Write Out Runtime Data.

Aug 01 18:24:10 nixos systemd-coredump[1192]: Resource limits disable core dumping for process 267 (plymouthd).
Aug 01 18:24:10 nixos systemd-coredump[1192]: [🡕] Process 267 (plymouthd) of user 0 dumped core.
Aug 01 18:24:10 nixos systemd[1]: systemd-coredump@0-1191-0.service: Deactivated successfully.
Aug 01 18:24:10 nixos systemd[1]: plymouth-start.service: Main process exited, code=dumped, status=11/SEGV
Aug 01 18:24:10 nixos systemd[1]: plymouth-start.service: Failed with result 'core-dump'.
Aug 01 18:24:10 nixos systemd[1]: plymouth-start.service: Consumed 4.842s CPU time, no IP traffic.
Aug 01 18:24:49 nixos su[1202]: Successful su for CipherJay by root
Aug 01 18:24:49 nixos su[1202]: pam_unix(su:session): session opened for user CipherJay(uid=1000) by (uid=0)
Aug 01 18:24:53 nixos systemd[1]: Started Process Core Dump (PID 1402/UID 0).
Aug 01 18:24:53 nixos systemd-coredump[1403]: [🡕] Process 1401 (Hyprland) of user 1000 dumped core.

                                                  Module libpcre.so.1 without build-id.
                                                  Module libbrotlicommon.so.1 without build-id.
                                                  Module libgraphite2.so.3 without build-id.
                                                  Module libdatrie.so.1 without build-id.
                                                  Module libselinux.so.1 without build-id.
                                                  Module libpcre2-8.so.0 without build-id.
                                                  Module libgpg-error.so.0 without build-id.
                                                  Module libgudev-1.0.so.0 without build-id.
                                                  Module libbrotlidec.so.1 without build-id.
                                                  Module libbz2.so.1 without build-id.
                                                  Module libexpat.so.1 without build-id.
                                                  Module libpangoft2-1.0.so.0 without build-id.
                                                  Module libharfbuzz.so.0 without build-id.
                                                  Module libthai.so.0 without build-id.
                                                  Module libfribidi.so.0 without build-id.
                                                  Module libGLX.so.0 without build-id.
                                                  Module liblz4.so.1 without build-id.
                                                  Module libzstd.so.1 without build-id.
                                                  Module liblzma.so.5 without build-id.
                                                  Module libgcrypt.so.20 without build-id.
                                                  Module libcap.so.2 without build-id.
                                                  Module libXdmcp.so.6 without build-id.
                                                  Module libXau.so.6 without build-id.
                                                  Module libwacom.so.9 without build-id.
                                                  Module libevdev.so.2 without build-id.
                                                  Module libmtdev.so.1 without build-id.
                                                  Module libGLdispatch.so.0 without build-id.
                                                  Module libz.so.1 without build-id.
                                                  Module libXext.so.6 without build-id.
                                                  Module libX11.so.6 without build-id.
                                                  Module libXrender.so.1 without build-id.
                                                  Module libpng16.so.16 without build-id.
                                                  Module libfreetype.so.6 without build-id.
                                                  Module libfontconfig.so.1 without build-id.
                                                  Module libxcb-errors.so.0 without build-id.
                                                  Module libxcb-res.so.0 without build-id.
                                                  Module libxcb-icccm.so.4 without build-id.
                                                  Module libxcb-ewmh.so.2 without build-id.
                                                  Module libxcb-composite.so.0 without build-id.
                                                  Module libxcb-xinput.so.0 without build-id.
                                                  Module libxcb-xfixes.so.0 without build-id.
                                                  Module libxcb-shm.so.0 without build-id.
                                                  Module libxcb-render-util.so.0 without build-id.
                                                  Module libxcb-render.so.0 without build-id.
                                                  Module libxcb-present.so.0 without build-id.
                                                  Module libxcb-dri3.so.0 without build-id.
                                                  Module libliftoff.so.0 without build-id.
                                                  Module libdisplay-info.so.2 without build-id.
                                                  Module libseat.so.1 without build-id.
                                                  Module libudev.so.1 without build-id.
                                                  Module libvulkan.so.1 without build-id.
                                                  Module libGLESv2.so.2 without build-id.
                                                  Module libdrm.so.2 without build-id.
                                                  Module libffi.so.8 without build-id.
                                                  Module libgcc_s.so.1 without build-id.
                                                  Module libstdc++.so.6 without build-id.
                                                  Module libpangocairo-1.0.so.0 without build-id.
                                                  Module libpango-1.0.so.0 without build-id.
                                                  Module libGL.so.1 without build-id.
                                                  Module libudis86.so.0 without build-id.
                                                  Module libsystemd.so.0 without build-id.
                                                  Module libxcb.so.1 without build-id.
                                                  Module libinput.so.10 without build-id.
                                                  Module libxkbcommon.so.0 without build-id.
                                                  Module libEGL.so.1 without build-id.
                                                  Module libwlroots.so.12 without build-id.
                                                  Module Hyprland without build-id.
                                                  Stack trace of thread 1401:
                                                  #0  0x00007f068e7a0adc __pthread_kill_implementation (libc.so.6 + 0x87adc)
                                                  #1  0x00007f068e751cb6 raise (libc.so.6 + 0x38cb6)
                                                  #2  0x00007f068e73b8ba abort (libc.so.6 + 0x228ba)
                                                  #3  0x00007f068eaa9aa9 _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold (libstdc++.so.6 + 0xa9aa9)
                                                  #4  0x00007f068eab4faa _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xb4faa)
                                                  #5  0x00007f068eab5015 _ZSt9terminatev (libstdc++.so.6 + 0xb5015)
                                                  #6  0x00007f068eab5267 __cxa_throw (libstdc++.so.6 + 0xb5267)
                                                  #7  0x0000000000449ebc main.cold (Hyprland + 0x49ebc)
                                                  #8  0x00007f068e73cace __libc_start_call_main (libc.so.6 + 0x23ace)
                                                  #9  0x00007f068e73cb89 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x23b89)
                                                  #10 0x000000000047b0a5 _start (Hyprland + 0x7b0a5)
                                                  ELF object binary architecture: AMD x86-64
Aug 01 18:24:53 nixos systemd[1]: systemd-coredump@1-1402-0.service: Deactivated successfully.
Aug 01 18:25:33 nixos systemd[1]: Started Process Core Dump (PID 1485/UID 0).
Aug 01 18:25:33 nixos systemd-coredump[1486]: [🡕] Process 1484 (Hyprland) of user 1000 dumped core.

                                                  Module libpcre.so.1 without build-id.
                                                  Module libbrotlicommon.so.1 without build-id.
                                                  Module libgraphite2.so.3 without build-id.
                                                  Module libdatrie.so.1 without build-id.
                                                  Module libselinux.so.1 without build-id.
                                                  Module libpcre2-8.so.0 without build-id.
                                                  Module libgpg-error.so.0 without build-id.
Aug 01 18:24:08 nixos systemd[1]: Received SIGRTMIN+20 from PID 267 (plymouthd).

I don’t know much about what any of this means yet, so I would really appreciate any advice you could give me. Thank you.

This means your main drive failed to mount. This probably means one of these things:

  1. You’re using an encrypted root, and a bug of some kind makes NixOS think the disk is unlocked when it is not (I’ve encountered this before, it’s one hell of a weird bug caused by incompatibility of the encryption library at runtime and in the init or something, I spent weeks trying to fix it before giving up and just reencrypting the drive).
  2. You’re using an encrypted root, and a systemd initrd, which fails to prompt for a password again if you enter the wrong password. I’ve also seen this, but thought it was fixed.
  3. Your drive is dying?

Could be some other serious hardware failure too. Get a backup of any important data before you play with this any more. If you could share the rest of the boot log maybe we can narrow down what exactly is wrong.

All the other errors are mostly noise, but let me explain them.

This was probably causing your login problems before, and may also be due to hardware failure (would not have guessed so without the later logs…). Sadly hard to tell what’s actually wrong without more detailed logs:

The nvidia error is a harmless kernel bug (too verbose logging) that’s been around and supposedly fixed for 3 years now, it’s there consistently for me too.

The bluetooth error seems like it probably breaks bluetooth for you. Somewhat normal to see bluetooth drivers failing, usually fixed by a reboot. Either way not as serious as your disk problems.

Effectively all the other stuff in the second log is just caused by your computer trying to boot without a main drive. It enters emergency mode (which is a little mini Linux system you can use to mount drives and otherwise debug the boot process, not your real system), and you try to run hyprland in it, which obviously fails and goes up in flames since there’s nothing on your system. I’m surprised it even finds a hyprland binary to run?

Yes, that script only runs when zsh is executed as the login shell by your user, which can’t happen until you’re logged in. This is true for other distros too.

What your script does do is start hyprland if you ever log in on tty1, but this isn’t needed if you’re running sddm since it is in charge of starting the graphical session. Your script may in fact interfere with this by starting a second hyprland session somewhere during the login process.

You may want to also configure the default session to be hyprland: NixOS Search

autoLogin should be doing all the work from there, I’m not sure why it doesn’t. Next time you have a working boot where it does not, could you share your full boot log with pastebin, hastebin or such?

1 Like

I just bought this drive, brand new for this NixOS install. I sure hope they didn’t send me a corrupted one. I will definitely make sure everything is backed up before potentially destroying my system. Thank you for this.

The drive in question that I am booting NixOS from is nvme0. df lists the boot partition as nvme0n1p1. It may also be important to mention I have multiple drives on here, one running Fedora, one running Arch, a timeshift backup for Fedora on its own drive (which will soon become a timeshift backup for NixOS), and an extra nfts hhd for storage which explains the ntfs support part of my config seen above. The other drives are also encrypted, which is why I also have this in my code, as per this discourse: Decrypting other drives after the root device has been decrypted using a keyfile

# Setup keyfile
  boot.initrd.secrets = {
    "/crypto_keyfile.bin" = null;
  };

After making the corrections to my config, I was able to get it to fail on me again (beautifuly). I collected the log from boot, but when I tried to paste it, it was way over the 3200 character limit. What’s the proper method for sharing something this large on here? While I did look through it, I can’t say I understand much of it yet. I just hope to eventually be able to do what you guys do. You make it look easy, meanwhile I feel like a baby giraffe learning to ice skate.

Let’s see if this works. I’ve never shared a gist from github before.
Okay, the embedding didn’t work. Here’s the link:

Yep, that works perfectly :slight_smile:

So this is systemd-cryptsetup, may be a bug somewhere yet. Do you know which drive is failing to mount? It seems to be one of these two (probably the second one): journalctl --boot -1 · GitHub

All I can find is this ancient redhat bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1456600

Can you try adding systemd.log_level=debug to your kernel parameters? You’re not somehow booting NixOS with a fedora bootloader are you?

This is indeed somewhat important, it shows that your boot process may not be perfectly thought out and have some kind of race condition ;p

How exactly do you intend for the drives to be decrypted and mounted, and in which order? Do you need them all to be mounted on boot immediately?

1 Like

Thank you for getting back to me, and sorry for the delay on my part. I’m not exactly certain which drive is failing to mount, but I believe it’s my boot drive for NixOS, which could be why its dropping me into another Linux environment instead of tty1. It does however let me log in afterwards with my root password, but I can’t launch Hyprland correctly.

I think this may be what’s going on. It may be that they’re all trying to mount asynchronously. I’m not sure how it works. I don’t need them all to mount simultaneously per se. I just want the other drives to mount later so that they’re accessible to exchange data manually as needed, and the backup drive for Fedora I don’t mount anyways. That will all soon be removed anyways. The level of stability NixOS brings makes Fedora unnecessary for me now. I just need Nix to boot reliably and to make sure my drive isn’t dying ;[.

I will add systemd.log_level=debug to my kernel params and see what I get and report back later. Thank you for sticking with me on this one.

Brand new hardware is more likely to fail. See Bathtub curve - Wikipedia

1 Like

No, that’s not necessarly true. The default hardware-configuration.nix marks all your drives as “neededForBoot”, which means that systemd will refuse to boot your system if any of them fail to mount.

Instead, it will boot emergency mode, which will indeed allow you to log in as root, but this is only the stage1 system and only contains a limited busybox system with the usual coreutils (tail, head, ls and the like) as well as some basic disk management tools, such as cryptsetup to decrypt your drives.

It’s not your actual system. Normally it is used to mount your drives, after which your root is switched to the actual root partition and your normal system continues the boot, but if any of the neededForBoot drives fails to mount we abort here so you can debug and manually continue if you want.

Personally I turn this feature off because I normally disable root login by password anyway, and it feels like a bit of a security hole: systemd.enableEmergencyMode

Either way, this is why hyprland will not work. Your system hasn’t even gotten close to the point where hyprland is available yet.

1 Like

This is good information. Thank you.

Thank you for clarifying this and explaining the process. Now that I think about this, I don’t like having root login by password enabled either. I turn this off on my web server for obvious reason, and I guess I just didn’t think about it on my personal computer.

All I would like to do is have access to these drives when needed. What alternatives would you recommend? Should I make a script that I can call to mount the selected drives as needed? I don’t know how straight forward this is on NixOS. Maybe you have something else entirely you would recommend.

I’m about to run some tests with the new option enabled. I’ll be back.

Okay, here’s the gist, no pun intended.

I was able to make it fail on the 10th reboot. Here’s what happened on all 10 reboots:

  1. It booted in, Plymouth + luks popped up, entered passwd, Hyprland loaded in, than it immediately kicked me back out to tty1 after psyching me out by flashing my desktop (good times). I then logged in to my user and ran Hyprland with no problems. Reboot.
  2. Same as 1.
  3. Booted in, Plymouth + luks, passwd, loads straight in to Hyprland as intended (yay), reboot (then it hangs for about a min 30 while some process stops, meanwhile screen remains black)
  4. Same as 1.
  5. Same as 1
  6. Same as 1
  7. Same as 1
  8. Same as 3, but instead of black screen on reboot, my Plymouth screen reappeared and froze for a min 30.
  9. Missed the passwd at luks one time, then it didn’t log into Hyprland first, it just went straight to tty.
  10. Finally it ate it after Plymouth and luks, and then I grabbed the log linked above on the 11th reboot.
    (The log is from the 10th reboot to be clear.)

While in this limited busybox system, during the failed boot, I checked what was available to see which drives failed to mount. I noticed that NixOS was mounted just fine, as was Fedora and the Fedora Backup (both btrfs), but the extra ntfs (extra) drive did not make it on, neither did my Arch Linux drive (btrfs).

I’m not entirely sure which drive is causing the issue, but this doesn’t happen when I boot into Fedora or Arch Linux. They boot in with no trouble at all. This log is ridiculously long, even searching for keywords using vim took me a long time, and all I realized is that I have a whole lot to learn. I’m assuming you guys have some sort of methods you use to troubleshoot these things and weed through the data, so I’m all ears if you have any suggestions. It also probably helps knowing how the kernel works. Thank you for helping me look into this, I know it’s a lot to read through, so I am very grateful for the advice.

Are you sure that’s the right boot? It doesn’t appear to enter emergency mode. The boot looks quite successful, but it eventually cuts off?

Not particularly. I hold off on reading debug logs until I have a rough idea what’s wrong, and then use that rough idea to filter through the debug log (in this case, I want more info on what causes the password prompt to fail supplying the password, so I searched for “password” and looked around a bit where I suspected this may be recorded).

Usually debug logs aren’t needed, you just have a particularly strange issue.


While we’re at it, are you able to share your full config? I want to look at your filesystem configuration, and see this boot.initrd.secrets hack you applied. Are you sure you need it? It’s intended for unlocking another drive with a key on another drive, without a password prompt. It’s possible that if you just remove that it will all magically work.

Not necessary, this is what the fstab is for. The devices you record in the fileSystems option will be added to the fstab file, and if they are not neededForBoot they will remain unmounted until the system is booted.

Once it’s booted, you can then manually mount them using e.g. mount /media/arch or whatever path you have it set to be mounted under.

Alternatively, we can mount the drives during stage2.

That said, I think the actual issue is somewhere else.

Would be good to get some logs for that as well!

And also for this. Knowing which process fails to shut down may help figure out what’s wrong.

1 Like

So I removed the boot.initrd.secrets hack and switched sddm for lightdm, and now everything works as expected. You were precisely correct. My autologin, Plymouth, even the mounting of my ntfs drive all works as expected now. I would have wasted so much more time looking for solutions that weren’t there. Now I’m equipped with a few more troubleshooting skills and a new perspective on how to look at these types of issues, thank you for all your help, TLATER.

2 Likes

This was the solution.

1 Like