I retract my statement, this looks perfectly safe and effective.
Good luck transporting a couch on a motorbike.
I click the reboot button on cockpit, which issues a shutdown --reboot command as root. I agree that sleep state S5 is powered off. From the acpi docs:
A computer state where the computer consumes a minimal amount of power. No user mode or system mode code is run. This state requires a large latency in order to return to the Working state. The system’s context will not be preserved by the hardware. The system must be restarted to return to the Working state. It is not safe to disassemble the machine in this state.
This likely means my system is failing to reach that s5/g2 state.
can you elaborate on why you suspect this? The cockpit reboot or shutdown button uses the shutdown command directly along with a --reboot or --poweroff flag.
onSubmit(event) {
const Dialogs = this.context;
const arg = this.props.shutdown ? "--poweroff" : "--reboot";
if (!this.props.shutdown)
cockpit.hint("restart");
cockpit.spawn(["shutdown", arg, this.state.when, this.state.message], { superuser: "require", err: "message" })
.then(this.props.onClose || Dialogs.close)
.catch(e => this.setState({ error: e.toString() }));
event.preventDefault();
return false;
}
(source)
thanks for the suggestion, could you elaborate on what this would do differently from the regular shutdown command that systemctl uses? thanks again
that is what I end up doing right now, but if I'm on vacation and I need to reboot, I'm fucked.
Ok. Cockpit uses the shutdown command to shut down[src], but systemctl poweroff might work. I will also attempt to revert bioses if msi supports it. thank you very much!
yeah journalctl logs show nothing relevant. I have disabled acpi and forced it(acpi=force), but that didn't fix this. There are a lot of different combinations of acpi settings I could try:
acpi=force noapic
nolapic
noapic
acpi_osi=“Linux”
acpi_osi=“Windows 2006”
acpi=ht
pci=noacpi
acpi=noirq
pnpacpi=off
But I found these from a guy which they didn't work on so I'm reluctant to try them.
lsmod | grep nouveau returns nothing, so I assume removing my gpu automatically stopped it from being loaded. that sorta rules out nouveau as an issue.
I have removed my gpu and the issue is still present.
The xserver-xorg-video-nouveau package was not installed, how else would I remove nouveau?
I get moving from reddit but just leave your comments up, this just made me have to do guesswork based on OP's reply.
I've been dealing with this bizarre issue on my Garmin Oregon 450 GPS, and I need help diagnosing and fixing them. For some reason, I can't catch a break with these undocumented unsolved mysteries. Here's the situation:
(Original)Stuck in USB Mode:
When I turned on the GPS, it shows the USB icon as if it's plugged into a computer for file transfer, even though it isn't. If I plug in a USB, it works for file transfer. The issue disappears when I cover the pins from the back case (with the USB port) to the main board with electrical tape. When I do this, the device works perfectly fine, but I need a more permanent solution without relying on tape(outside, if I want to load maps I will need to disassemble my gps). This issue was sort of fixed by resoldering the CMOS battery(which garmin says is not needed - 
)
Power Button Problem:
After I desoldered and potentially re-soldered the CMOS battery, the GPS starts when I press the power button, but it doesn't boot fully. It powers on but does not complete the boot process. The thing with the CMOS battery is, I don't know if CMOS is the right term. The battery's voltage is lower than a standard cmos bat, at a shocking 0.24V. This causes me to think it's either completely cooked or it's a specialized battery. Either way, garmin's user manual(link) says it is not needed. See page 36, saying "Data Storage Life: Indefinite; no memory battery required"
Steps I've Taken:
I've desoldered and attempted to re-solder the CMOS battery (model 10N4). I've tried electrical tape on the USB pins, which temporarily solves the ghost USB issue completely even if I press the power button. I've put a little bit of isopropyl alcohol down the USB port(device was off, port was disconnected), it's still drying as I type. I have NOT disassembled any further than the secondary back plate with the battery slots. If someone thinks that will help, I will try to.
Can anyone contribute to this discussion? I have found radio silence online. Thank you very much.
Photos:
The main board of the GPS, with the pins covered up. Back view
The back plate - note the corrosion
The USB pins uncovered.
An overexposed mess showing my shoddy soldering job of the button cell.
Thank you for reading this, and for any ideas you may have.
Yes, I've always made sure to use
update-gruband checked cmdline to make sure it has the correct parameters. Regardless of acpi=force or acpi=off, it would still hang.