Alienware Aurora R7 - Not shutting down

Hey guys,

So yesterday I installed MX Linux standard version (4.19 kernel) dual booting with Windows 10. Unfortunately, the system was hanging every time I tried to shutdown (screen goes black, but monitor and tower on still). So after posting on their forum I tried their suggestions:

  1. Turning on AHCI in BIOS>SATA mode (turning off Raid).
  2. Downloading their latest AHS (Advanced Hardware Support ISO) which has the 5.6 kernel.

Neither of the above situations worked, so I thought maybe it was MX Linux itself and thought I'd try Manjaro instead with the 5.7.9-1 kernel.
However, I'm still having the same problem (hanging on shutdown) but I came across this post on this forum: ACPID Settings So, wanted to check that if I managed to actually follow the Arch instructions and configure the ACPID settings would it affect my ability to boot the system and/or boot into Windows?

I've also disabled; fastboot, secureboot & TPM settings. So only two suggestions I have left are changing ACPID settings and resetting/updating BIOS. However, I'm wary of doing that in case it breaks my entire system. Hence, my question about the ACPID settings and what happens to Windows if I actually manage to change them...

ETA: Forgot to say thanks in advance to those of you who post any answers/input :slight_smile: and thanks for reading.

So what happens when you do

systemctl poweroff


Thanks for the quick reply and same thing happens as when I don't use the terminal to shut down - Black screen, but tower still on.

The only time I can shut down successfully is when booting into windows on my SSD and shutting down from the desktop or login screen.

I was hoping it would give us some output ..
But if you are to follow that acpid page .. it looks like you install acpid and start the service of the same name.

sudo pacman -Syyu acpid
systemctl start acpid

Sorry for the delayed response, I went to bed just before posting that.

Also, I'm completely new to Arch/Linux, but I'm really trying to learn so I apologise in advance if my next question sounds stupid but: I don't see how systemcl is the problem here? As clearly the command does execute as when I typed in systemcl power off it actioned it the same way clicking shut down does in the menu - It tries to shut down, but it physically doesn't.

Also, in hindsight I'm thinking that maybe the Acpid settings page isn't the solution as it relates to what happens when you physically click the power button right? Whereas my issue isn't with that, it's with the system not shutting down when told to do so via menu or terminal...

ETA: I've also found this suggestion, but was wondering if it would still work? As it was written a couple of years ago. So I wasn't sure if it would no longer apply to the newer kernels...

Okay, so link I posted to earlier fixed the problem. I followed the instructions by doing in terminal sudo nano /etc/default/grub

  1. Adding initcall_blacklist=dw_i2c_init_driver” to the GRUB_CMDLINE_LINUX_DEFAULT line.
  2. Saving the file with these new changes. (Hold down Ctrl & O) then exiting from nano (Ctrl & X)
  3. Updated GRUB. By doing in terminal sudo update-grub
  4. Rebooting/Shutting down my system to test if it had worked and it had. Though I'm not sure how :thinking:

Either way, I've learnt another Linux lesson in the process which is... Going forwards I won't be so quick to discount advice/guides even if they're a few years old.

ah. thats an esoteric module. I dont think I've seen it before.
Good find.

Not sure what an esoteric module is, but thanks :smile: It was one of the very first solutions I came across when researching a solution - But as I said due to age I discounted it as no longer applicable

a Module is something loaded usually for some hardware .. sometimes vendors have funny broken ones .. i2c and iTC both are common ones from things like asus .. or in this case 'design ware' .. while 'dw_i2c..' seems to fall neatly into that category .. I had just never seen it before.

Since its a module/vendor/hardware things it also makes sense it continues to be applicable (assuming the module/kernel is never 'fixed'..but that is a lot easier with vendor involvement, and they rarely care and from the kernel side its considered an 'edge' case)

Ahh that definition about modules makes sense, thanks for the clarification.

Also, that was my thinking too in that: As it seems to be an Alien/design ware problem (several Ubuntu users posted about the issue/solution) I realised the issue probably still exists as its clearly hardware related for Alienware products - Well the R series anyway.

Whereas when I first read about the issue and suggested solution, I assumed that whatever was triggering the issue two years ago would have been fixed in a Dell update by now. Clearly not :unamused: My next system will definitely be based on Linux/open source- I've got my eye on the Thelio by system 76 :slight_smile:

Eta: removed word Foss and replaced with Linux/open source seeing as the Thelio certainly isn't free :smile:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by