Edit /etc/systemd/logind.conf and make sure you have
which will make it ignore the lid being closed. (You may need to also undo the other changes you've made.)
Then, you'll want to reload logind.conf to make your changes go into effect (thanks to Ehtesh Choudhury for pointing this out in the comments):
systemctl restart systemd-...
Laptop batteries typically have onboard firmware to control safe charging & discharging of the battery, report battery charge level to the OS, and prevent thermal runaway, which is what will cause an Li-ion battery to explode (or more accurately, catch fire). Most modern ones also contain mechanical failsafes to prevent such fires & explosions.
To disable the Lid Switch:
Open the file /etc/systemd/logind.conf as root.
Find this: HandleLidSwitch
If it's commented, uncomment and change the value to ignore. The line after editing should be:
Restart computer and your problem should be gone. Or better restart logind service:
sudo service systemd-logind restart
Install GNOME Tweak Tool and go to the Power section. There's an option to disable the automatic suspend on lid close.
I compared dconf before and after to find the option, but it turns out that's not how it's implemented. Instead, Tweak Tool creates ~/.config/autostart/ignore-lid-switch-tweak.desktop. The autostart is a script which ...
I think all batteries can explode. The question is if Linux (an operating system using the Linux kernel) will generate more heat or not. With good use of the fan (equally good use of the fan as other operating systems might employ), the cooling should be equal or better, thus resulting in a similar (or perhaps even reduced) risk of battery explosion.
I know this is an old question, but the following unit file worked for me to run a script upon resume from sleep:
ExecStart=<your script here>
I believe it is the After=suspend.target ...
This question is old but I just came across a working fix for this.
As it turns out, the issue was caused due to the USB drive being unmounted during the LVM setup process. It might've been a bad USB connector or USB drive.
There is a very easy fix for which you don't even have to reboot or re-do any of the setup again.
Press esc to enter the menu of the ...
If “certain times” aren’t fixed, i.e. you want to specify manually when your system enters and leaves “performance mode”, you can simply stop and start cron:
sudo systemctl stop cron
will prevent any cron jobs from running, and
sudo systemctl start cron
will re-enable them.
You could also check out anacron instead of cron, it might be easier to tweak ...
So, it sounds like you have not installed a boot loader (e.g. grub) on the disk. This means that although you have a valid OS on it, there is no way to boot it and so you can't use it.
You need to attach the HDD to a working computer (you can use a live CD), set up a chroot environment and install grub on it.
Mount the partition you will be using as / (I ...
The problem I was having involved the "Disable While Typing Enabled" feature of my trackpad. These are the steps I used to solve it.
Make sure xinput is installed.
Type xinput to find the name of the trackpad device. mine was "ETPS/2 Elantech Touchpad"
xinput --list-props "DEVICE" to list the properties of the device
Go through the list until you find ...
I would consider two approaches
Leave the scheduling untouched but run all cron jobs under nice, and possibly even ionice:
0 * * * * root ionice -c3 nice /some/command and parameters
Disallow any cron jobs during certain times. Remember that any user who can create (or remove) the flag file can control this approach. That might work if you want to ...
I'm pretty sure that an OS has no capabilities to destroy a battery (be it Linux OS, Windows, etc.). A malfunctioning program (and not Linux by itself) can overload a laptop/PC up to the point that, for example, it can enter CPU thermal protection.
But a fresh Linux install will not damage any hardware (if it does, than something is terribly wrong with ...
Yes, often you can boot and run different computers from the same hard disk drive with linux, but if one of the computers needs a proprietary driver (that does not work in the other computer), for example for the graphics card, there might be problems. You need to boot in the boot mode, that linux was installed in (UEFI mode or BIOS mode).
But you can '...
It's probably not bad if they're "Bad", when you run on the AC power. When running on battery, the "Good/Bad" settings may or may not help. You can toggle them and observe the effects, but should you toggle them if you want to achieve the highest power-saving? I agree with mavit's answer that the powertop is primarily a diagnostic tool. There are other ...
As an alternative to writing and enabling a unit file, you can also put a shell script (or a symlink to your script) into /lib/systemd/system-sleep/.
It will be called before sleep/hibernate, and at resume time.
From man systemd-suspend.service :
Immediately before entering system suspend and/or hibernation
systemd-suspend.service (and the other ...
While the solution proposed by Mirzhan will probably work, there is a much more elegant way using the services.logind.lidSwitch and services.logind.lidSwitchDocked options.
Now, you can just write
services.logind.lidSwitch = "ignore";
These options also have types provided so an invalid configuration would be detected at build time.
You do not need to.
On my notebook I need to press the button Fn before F10.
That is, however, irrelevant to what X input events you need to simulate.
What you have to remember is that the Fn key is never seen on the wire between your keyboard and your computer. It is handled entirely by the microprocessor in the keyboard itself. What comes over the wire ...
Powertop is not a permanent tool, as you know, so you will have to setup your system to run the commands through sysctl, udev, systemd units, scripts, whatever...
In order to see what commands are used by powertop you will have to run powertop --html BEFORE MAKING ANY CHANGES, that is, BEFORE toggling the settings from Bad to Good. If you already tuned for ...
Unfortunately, the inhibitor routes didn't seem to work as advertised for me on openSUSE Tumbleweed (42.1) using GNOME. But, I had success with Systemd masking:
systemctl mask sleep.target suspend.target
To undo the mask, you can use unmask:
systemctl unmask sleep.target suspend.target
UEFI has nothing to do with power management. ACPI manages power. UEFI indicates modern firmware than BIOS and newer platform, thus improved power efficiency. This might be a correlation.
The PM subsystem is different from UEFI. Linux includes a whole range of power management functionalities, though unrelated to UEFI, like cpufreq, intel_pstate, pcie_aspm, ...
I just got my T440s, installed Arch Linux on it and can confirm that Fn+Esc locks the Fn keys to their "proper" function. No user-intervention needed to get it working, and Arch just installs the stock kernel so no magic pathes present. The thinkpad_acpi kernel module is loaded, tp_smapi not (and refuses to be), haven't tried without them.
Side effect: a ...
I don't know why you're looking for corroborating evidence from the system, when you have solid empirical evidence. The battery won't hold a charge. Period, end of story.
I'd be happier if I saw a high charge cycle count. Lithium ion isn't good for more than about 500 charge cycles.
Another datum, which won't appear in the places you've been looking, is ...
There is a configuration option services.logind.extraConfig.
Open your NixOS configuration file (/etc/nixos/configuration.nix). Assign a string "HandleLidSwitch=ignore" (or whatever you would usually put into /etc/systemd/logind.conf) to that option:
services.logind.extraConfig = "HandleLidSwitch=ignore";
I met the same bug. Your workaround didn't work for me. Your trick is simply a trigger that makes the bug not to fall in. I digged in a bit and found a nice guy with a solution that might help others here as well.
The main problem is that the bug we met here causes the monitor which is scrolling into the other to have a virtual screen with the size of both ...