told you to uninstall it completely…
and i didnt notice that you are dual booting, so enabling ahci when using windows is a problem… you have to switch it back, and search for guides on internet how to enable ahci on windows
in the stuck screen enter into tty: ctrl+alt+f2 or f1-f6 keys, enter your username and password, and uninstall envycontrol:
pamac remove envycontrol
reboot:
systemctl reboot
I thought I said I was dual booting in my first post ;-; maybe I misunderstood how to re-enable Nvidia’s drivers looking at their docs so my fault there. I got windows back working switching to raid, but now Manjaro just drops me into an emergency shell. Should I find a way to make AHCI work with windows and switch it back to make it work?
i didnt noticed it … and with raid enabled you can forget about a working suspend…
you can check the last post here:
https://superuser.com/questions/1280141/switch-raid-to-ahci-without-reinstalling-windows-10
and the only thing you did was switching envycontrol to hybrid?
and you cant even enter into grub?
Manjaro stopped working after I switched back to RAID to get windows back. I can enter the grub CLI from the selector but if I select Manjaro I get dropped into the emergency shell
could be related to the 3060 nvidia card, which has problem booting with the latest drivers… so switch back to ahci in the meantime and try doing this:
I’ll pick this back up tomorrow, don’t really have time right now. I guess I should try to solve the windows issue first and then switch back to ahci and uninstall?
well i would rather first fix manjaro, because what if the switching to ahci doesnt work and you end up with unbootable windows and also with unbootable manjaro, since we dont know now for sure that envycontrol is the reason that you are stuck at the dev clean screen, which very likely is the reason, but anyway, dont risk it with windows until manjaro is fixed
Right now windows works and is bootable, I’m using raid. Wouldn’t switching to ahci to fix manjaro break it? I was planning on following the guide you linked to make the switch safe for windows first and then switch to fix manjaro
yes i understand, but, we dont know what causes you to be stuck on the dev clean screen - its probably the envycontrol; so first fix manjaro…when manjaro is fixed, you can switch windows to ahci, using the commands that are mentioned in the link, or just use the instructions in the last post in the link, that dont require any commands. As i understand the last post is, you switch to ahci in bios, and that make windows not boot and if windows doesnt boot 3 times in row, you can enter the safe mode, where the ahci drivers will be automatically installed on windows… but im not using windows, so you do your own research on this… but first lets fix manjaro.
I enabled ahci and got into tty, removed envycontrol and rebooted but manjaro is still stuck. What can I try?
At which point does it stuck? Is there a verbose boot screen?
At least, are you able to boot a Manjaro Installation Disk? Might be more comfortable (webbrowser and internet available), since you have no idea how to fix it on the emergency console.
I’m not in the emergency console anymore, I was able to get regular tty and boot with cli. The boot screen isn’t verbose, it just gets suck at “clean …”. Should I enable debug flags or check logs somewhere once I’m in?
Most likely, since you installed envycontrol, there must be configs which blocks the boot process… Have a look at these folders and rename the suffix or delete the files if you think they refereed to envycontrol :
- /etc/modules-load.d/
- /etc/modprobe.d/
- /etc/X11/xorg.conf.d/
To get a verbose boot screen, you need to remove quiet from the kernel parameters. See grub.
I don’t really know what to look for related to envycontrol, but the config in modprobe had some blacklists in it, not sure if that’s normal.
With a verbose boot, it seems to get stuck on
sof_sdw sof_sdw snd_soc_register_card failed -517
The only other error I can see is a
Bluetooth: hci0 Malformed MSFT vendor event: 0x02
None of these errors should block the start of your display-manager.
That is what I expected. You can try this for example on the TTY:
View
curl -s "https://notabug.org/megavolt/random-scripts/raw/master/lognconf-report.sh" | sh
Upload
curl -s "https://notabug.org/megavolt/random-scripts/raw/master/lognconf-report.sh" | sh -s -- upload
It collects pretty much everything… I wrote this script. So if you trust me, then run it and share the printed link.
However without information, I cannot suggest anything.
And here we have the problem:
ott 17 14:42:54 sddm[742]: Failed to read display number from pipe
ott 17 14:42:54 sddm[742]: Display server stopping...
This file i generated by envycontrol:
---/etc/modprobe.d/nvidia.conf---
# Automatically generated by EnvyControl
options nvidia-drm modeset=1
options nvidia "NVreg_DynamicPowerManagement=0x02"
remove it:
rm -fv /etc/modprobe.d/nvidia.conf
and reboot. Any change?
If not then add the gpu modules to the initcpio. Edit the file /etc/mkinitcpio.conf
nano /etc/mkinitcpio.conf
and replace
MODULES=""
with
MODULES=( i915 nvidia nvidia_modeset nvidia_uvm nvidia_drm )
Note that you need to run mkinitcpio -P afterwards. That will load the gpu driver as early as possible in that specific order.
Reboot. Any change?
Removing the envycontrol file did work, thanks for the help! The sleep issue seems to persist, would you recommend following the steps on the device’s arch wiki? Also, are you able to see anything from the logs about the shutdown issue? Thanks!
Do you really know what issue it causes… I would not recommend doing anything if you know at least the reason.
I have only the current and the previous boot log. There is everything alright, or does it hang on that shutdown at 14:18:21 ?
Look at the journal list:
journalctl --list-boots
and get the log of the faulty shutdown. There are numbers (column IDX). Then target it like that:
journalctl --boot <number> --no-pager
example:
journalctl --boot -11 --no-pager
sleep issue seems to be caused by this
Also every shutdown is faulty, I always have to hard kill it with the power button, so any log should be fine. Here’s one:
https://gist.github.com/Merlo17/7f4ce71d4fb0c06b5acdada6341cc816