Long story short: We have one of those little $100 Chinese mini PCs running 18.04 LTS. ("Wintel Pro" / "Wintel Box") It thinks it has a battery, possibly because it thinks it is a laptop. The "battery" level notifications - that I have tried a million ways to kill - are driving me nuts because I'm trying to use this machine to run a looping slideshow while the workplace is open.

(Update: It wasn't just the battery notifications on the desktop, either. Sometimes it would just shut off randomly. I have a nearly identical model without a desktop and it exhibited random shut-offs until I applied the same fix detailed in my own answer below.)

Thought I might have had this fixed but HAHAHA NOPE

Related question: Why does Ubuntu power management set a battery as the default power supply on a desktop machine?

This is where someone asked "What is the output of laptop-detect -v?"

It is: We're a laptop (non device ACPI batteries found)

But we are emphatically not a laptop, and we don't want to be a laptop. How can we not be a laptop?

CPU is Intel Atom x5-Z8350. Do let me know if additional information is required. The fault may have nothing to do with Ubuntu but I live in hope Ubuntu might have the tools to fix it.

(Aside: LibreOffice Impress slides run fine, but I would not recommend these machines for high-resolution video playback.)

Top side of mini PC

Bottom of mini PC

LSHW output: https://pastebin.com/e5XXp8A0

Also, thank you to @Sri for reminding me that I'd already tried turning off "Notification Popups" and it did as much good as a piece of paper towel against a flood. The "battery" notifications seem to cheerfully disregard this setting - even with notification popups ostensibly OFF, the nonexistent battery still breaks through.

Update: Apparently there is an "axp288" device inside this miniPC, and apparently there is some discussion somewhere on the LKML about this: https://lore.kernel.org/lkml/[email protected]/

Is there a way to get this code into my instance of Ubuntu? Would it even do any good? (Maybe it's already there?)

  • 2
    Suspect this is a hardware issue, since other mini- and micro-PCs (i.e., Intel NUCs and Supermicro Atom SBCs) don't freak out because of a non-existent battery. However, I also hope I am wrong. Would you mind, please, finding the parts model number from the serial number sticker, and telling us the make and that parts model number?
    – K7AAY
    Jan 29, 2020 at 23:48
  • Sure, I've added pictures of the mini PC to the post as well as a pastebin of the output of sudo lshw. Despite the model being W8 Pro, it shipped with Windows 10 (probably Home, I don't remember). I don't recall any weirdness with a "battery" there, but I also wasn't using it for long. I have an identical unit at home that is still on W10, and I don't observe this kind of problem. The 32GB of "ROM" refers to the eMMC memory used for the OS and storage. It is not a lot and it is not fast, but it works. Jan 30, 2020 at 0:54
  • 3
    Have you checked for any BIOS/firmware updates from the vendor? That may make a big difference in how things work.
    – ubfan1
    Jan 30, 2020 at 1:00
  • "Lifetime technical support from store vendor" advertised on Amazon site. You may need to take them up on that.
    – K7AAY
    Jan 30, 2020 at 16:25
  • @ubfan1 Well, American Megatrends makes it so that all of their BIOS updating is done through a Windows-only tool. So unless I want to try running their tools in Wine and risk bricking the whole system, then basically I might as well just go back to Windows. Jan 30, 2020 at 19:04

3 Answers 3


I'm an upstream kernel developer and the author of the kernel-patch linked from the original post.

I just discovered this thread today, this is a known issue with some of these Intel Atom x5-Z83xx based boxes, they use an AXP288 PMIC and often the BIOS does not turn off the fuel-gauge (battery monitoring) part of this chip.

The driver for the AXP288 fuel-gauge contains a list of devices like this: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/supply/axp288_fuel_gauge.c#n679

And it will automatically disable itself for devices on this list.

So the proper fix for this, which will make future Linux versions work out of the box, without needing manual configuration, is to add your device to this list.

I can do this for you, but I need some information about your model to be able to do this.

Please as a regular user in a terminal run:

grep . /sys/class/dmi/id/* 2> /dev/null

On the device and then copy and paste the output here, or send me an email with it at "Hans de Goede [email protected]".

That will give me the info which I need to add your device to the no-fuel-gauge list.

  • Right on! Here you go: - The output from the 2GB model mini PC featured in this post: pastebin.com/03R32ScV - The output from a very similar but 4GB model mini PC that I think has the same issue - making the same fix of blacklisting the fuel gauge stopped a spate of mysterious shutdowns (even though it wasn't running a desktop environment, so no visible-to-me gauge to also complain about): pastebin.com/2H3aW1CZ Thanks very much! Mar 19, 2021 at 16:27
  • 1
    Sorry for being so slow to respond, I somehow missed the notification that there were new comments on this thread. Thank you for providing the DMI info for the 2 models, I've submitted a set of patches upstream to automatically disable the axp288-fuel-guage on these devices without needing to disable the driver: lore.kernel.org/linux-pm/… Jun 17, 2021 at 19:27

I think I fixed it. At the very least, the battery gauge is gone from GNOME.

Finally, no battery gauge!

In responding to @trond hansen's comment, and trying to find my wattage, I found I had an "axp288" something-or-other, and searching more about that, I found that the axp288 could be blacklisted in the kernel. (Perhaps check under /sys/class/power_supply to see what you have, if you are experiencing a problem like this.) It seems to be on a model-by-model basis, though - perhaps the axp288 is part of a legitimate battery sometimes. Anyway, I wanted to see if I could somehow add my own mini PC to that list, ideally without having to modify and compile the kernel myself!

But for now, you can just disable the battery gauge on your one machine:

sudo nano /etc/modprobe.d/blacklist-axp288.conf

Type in blacklist axp288_fuel_gauge then Ctrl+X to exit, Y to save changes, and Enter to confirm the filename. Then reboot. I hope this is the end of the misery. If I never come back to this thread, you can assume it was.

Shoutouts to the openSUSE forums for the fix! https://forums.opensuse.org/showthread.php/531934-Leap-15-on-Intel-Atom-power-supply-fuel-gauge-driver-failed-endless-errors


While hardware experts figure out who and why we are ;), your issue with presentation interruptions can be resolved perhaps by turning off the notification popups in settings.

enter image description here

Yeah, we tend to overlook simple things, with existence becoming complicated day by day.

Edit: My bad, I assumed the desktop interface. The battery notification settings can be handled in terminal with gsettings. Please refer the answer here: https://askubuntu.com/a/572159/37991

  • Thank you, but I have the "Notification Popups" setting OFF and it is blithely disregarded inasmuch as the "battery" ones come up anyway. Maybe I'll turn "Lock Screen Notifications" OFF too just for the heck of it. Also there isn't an application specific setting for battery or power that I can see. I've also already used dconf Editor to do something similar with the battery notification settings - that is, crank the thresholds down to 0% so it's less likely that I'll see them. I haven't seen them since, so I'm cautiously optimistic. But I think there ought to be a real fix. Feb 4, 2020 at 23:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .