If I retrace my steps, I am guessing if you disconnect the battery and then leave it off the charger for approximately 5-10 minutes, it should reproduce what I did.
To prevent this from happening, I’m not exactly sure why it happened and my best guess is the battery was drained completely and triggered some kind of safety circuit. My guess is that Linux suspend doesn’t hibernate and has a tendency to drain the battery completely. On my Windows installation, the system will go into hibernate and shut down the system.
I’m not that familiar with Linux, but it seems the solution is to configure the OS to suspend the system to disk after a set period of time, or to turn off the system if you intend to keep it off the charger for a considerable time. The other issue is related to battery drain during suspend, which is probably much faster in Linux than Windows for now until the software support improves.
I noticed something that appears to be connected. I left my Framework in standby and disconnected the charger just to run the battery down so that it wouldn’t be charging at 100% all the time - give it a bit of a rest.
But I went on a business trip and forgot to plug the charger back in. When I returned, the battery was completely empty as expected - but what I did not expect was that it did not start charging again when I plugged the cable back in. No amber LED and the power supply remained cool. Nothing happened when I pressed the power button. Nothing was making it charge.
Before I really started to panic I let it sit for a bit and when I came back some time later the amber LED was on. Went out to run some errands and by the time I got back a few hours later the LED was white. I haven’t powered it up but if I did I’d expect this to be a cold boot.
@Kieran_Levin stated that the little standby battery that’s usually a lithium CR2032 is a new rechargeable type charged off the main battery. My guess is that as long as it has a charge it will operate the recharging logic and LED status as normal, but if the main battery goes empty and stays there for long it will also empty and cannot activate the charging procedure (USB PD negotiation) or the status LED. However the main battery is probably being slowly charged by USB default (non PD) power along with this little battery, and once the little battery recharges sufficiently, it negotiates USB PD with the charger, activates the status LED and starts charging the main battery at high power.
This takes time. Leave it for 5-10 minutes.
But I wonder if the BIOS settings have been wiped? That’s another function of this battery. I’ll have to power it up and test.
Edit: date and time is good, it was a cold boot as I suspected. BIOS settings seemed to be retained.
I’ve ran into this issue just now this morning (left laptop playing video and it died). Pressing power button it blinks red twice and nothing happens. I have power plugged in so will wait and see what happens.
In any case, if it does eventually boot it would be great to fix or provide Linux configuration suggestions to avoid having to wait this long (been charging for 10-20 minutes) without being able to use computer (should be able to boot even if only have power with minimal charge, while battery plugged in).
Will update on outcome of whether it eventually powers on.
exact same issue also batch 5. Unplug the battery and it works. the battery also discharges abnormally quickly when in sleep with the lid shut. I’m losing 30% charge overnight. then I left it in sleep for a week and it would not power back on.
Thanks for the reports on this, everyone. We definitely are interested in more detail to debug this. Could you share:
What version of BIOS you have (in Windows, this is visible in System Information)
Whether any other USB-C charger you have available (even a phone charger) results in different behavior when the Framework Power Adapter isn’t making the charging LED come on?
The serial number of your system (PM it to @FrameworkBee ). This is on the QR code in the front left Expansion Card bay.
We believe there is a BIOS 3.06-specific issue where a system that has it’s battery drained far enough in a specific way ends up in a state where USB-PD power adapters won’t charge it. We’ve identified a workaround for getting out of this state:
If you are using 3.06 BIOS (the default BIOS Batch 5 and 6 ships with), the current workaround until we have an updated BIOS is:
Plug in a basic USB power adapter to let the laptop trickle charge for 30 minutes. When doing this, make sure the power adapter you are using is a basic, non-USB-PD one, like an adapter that uses a USB-A to USB-C cable, like in the image below. If the charging LED does not come on after plugging this power adapter in, you may be facing a different issue.
hmmm ive tried all the steps provided throughout this board and nothing. it won’t turn on anymore. nor does the led or power turn on when plugged in. nothing lights up. i even disconnected the battery to see if that was the issue. this doesn’t seem to bode well for framework if my laptop is already dead if it hasn’t even been used much. I thought it was think whole standby thing.
@Fraoch Thank you for mentioning RTC battery. I have a Batch 4 I installed the 3.06 BIOS upgrade on so I could dim the power button and also run without battery for playing around. I had the laptop in my bag for a week and change without using it and came to find it dead.
Connecting a USB-A to USB-C cable connected to an old 5V@2A adapter didn’t light up on the right side, nor did leaving that connected for 30 minutes before attempting to then connect my framework OEM USB-PD connector to the left side. Nada. Even leaving the USB-A right side connected overnight.
Was going to read thru once more before contacting support… but saw that and was like… OK. For others’ information, I opened laptop, unplugged battery, used spudger to push RTC battery out from the left side to the right per the arrow on the board. Then I reconnected top case ribbon cable and tapped power button a few times to discharge any caps. Re-inserted RTC battery, reconnected main battery, closed laptop. Once I did that, the tip from this post worked. I gave it 10 minutes on non-PD power on the right side, then connected PD on the left, and it lit up!
Interestingly enough, my battery level is at 92% right now. Not sure if it originally drained to zero to trigger issue originally or if it still had charge. For what it’s worth, when I had put it away, it was at 95% charge and I turned it off when done, so I was questioning the drained battery cause a bit. Entirely possible it was drained though and just leaving it on the 10W non-PD overnight got it this high. Either way, no lights on the charging ports during that time with either adapter, and power button didn’t do anything until disconnecting the RTC and battery. I did have to reset my BIOS settings of course.
Does anyone have thoughts on how to properly configure a Linux distro to prevent this happening? There are two ways computers ‘sleep’ with Linux (at least with systemd.) They can suspend, which means saving state in memory and entering low power mode. And they can hibernate, which means serializing all memory to swap and then completely shutting off. The problem here seems to be with batteries draining when a computer is suspended, but not hibernated. However, as far as I can see, Fedora, with default install options, does not configure itself with enough swap space to hibernate. It seems that the laptop entering suspend, but not hibernate is what is causing this problem. I am not sure what the situation is with Ubuntu. Now, we could choose a different distro or configure manually. But given that Fedora is one of the two ‘officially supported’ Linux distros with tutorials on the Framework website, I think it seems reasonable to ask for support for some sort of sleep without disabling the battery on this distro.
Weirdly, however, I dug through the Fedora 35 thread, and I didn’t see anyone with this issue. So maybe it’s just me that having this problem on Fedora. If you’re reading this, please let me know if I’m misunderstanding anything or if you’ve found a satisfactory way to configure your system without this becoming a problem
I’m not a Linux pro but I remember vaguely when I was using it there was a recommendation that your swap space be at least your memory. So it’s possible people following that advice will never hit this issue? The other possibility is that perhaps the automatic installer just picks a swap space based on your Disk size and not based on your System Memory so it can vary depending on your system configuration.
Lastly, it’s possible to have this happen for everyone but nobody else is leaving their system on suspend until the battery dies and using Linux simultaneously.
Either way, I don’t think this is a Framework specific issue - I have a Clevo laptop that actually bricked its battery in a similar situation, so if there’s no permanent damage I think we’re getting lucky.
Well, this is REALLY BAD. I left my laptop (batch 4 DIY, LUKS-encrypted Debian 11) off during holidays, I now need to do some urgent work and it doesn’t turn on.
Happy New Year, I guess.
Edit - Apparently BIOS 03.07 which is now available solves this (while possibly preventing your laptopt to boot-see below). Batch 4 shipped with BIOS 3.02. May I suggest emailing owners for this type of bug and update ? - Apparently an email was sent about this - just not to all users ! Edit 2 :After the BIOS update, it won’t boot - my WD Black 1TB NVME is not found. This is apparently fixed with (yet another!) firmware update which can’t be done unless you have a full Windows 10 on the same system (WD dash control also requires Internet) Spent most the day installing Windows to USB - only managed to do this with WinToUSB free edition on another Win 10 system. Edit 3: It seems EFI on the NVME was zapped when BIOS was upgraded by USB/EFI method, I was able to restore it by following the GRUB EFI reinstall guide at the Debian Wiki with some variations. See this thread for more details.
In the end I spent 2 days chasing after this and getting back the laptop working again.
I had good recent backups, restoring to be able to boot again was the last fun part and worked. Thanks @another user for the hint! Never ever suspected the BIOS USB/EFI upgrade method to bork my system like this in 2022.
Probably UEFI firmware lost track of your OS. Just use a recovery medium to enter the UEFI shell (Ubuntu’s live image or Arch install or w/e), type in FS0: (or whichever disk that’s displayed that looks like your boot media), then find your boot .efi file and execute it (e.g. if grub it’s probably grubx64.efi or something like that). The usual cd and ls commands work in the UEFI shell once you’ve selected your drive (again, probably FS0:).
Once there, reinstall your bootloader to your boot media (e.g. grub-install if you use that). If you’re using Ubuntu or something else that insulates you from the bootloader installation process, you might be able to get away with reinstalling the bootloader package.
I was having the same issue. I used @dmac8086 's suggestion of disconnecting both the RTC battery and the main battery and that was the only way I was able to get it to boot!! I’ve been working on fixing this for several hours and this is the first time I’ve had any luck.
Interestingly, my battery power was at 37% when it booted up, which may have been because I had it trickle charging for awhile, though no LED lights came on and there was seemingly no power in the laptop.
I am having the same problem. Previously, the same pattern of battery fully discharged during suspense/sleep in Linux. Motherboard reset brought it back alive.
This time, it was actually full shutdown yet battery drained completely in a few days. Motherboard reset (CMOS cell out, battery disconnect, wait, etc) did not help. Completely unresponsive.
However, with only the battery disconnected, it would power on and boot up normally, but when it is reconnected, completely cold and unresponsive again.
Tried the trickle charging trick with a 5W phone charger without success.
I am on BIOS 3.06.
Contacted support but unsure what else to do apart from treating this as a plugged-in desktop.
if the laptop is working without the battery, it could be an issue with the battery you have or the battery connector on your mainboard. Support should get back to you next week, but for now it seems like you’ll have to stay tethered unfortunately.
Thank you Azure. Reached out to support and the diagnosis is battery replacement and potentially main board replacement too, both out of warranty.
The problem now is that because of work relocations since buying the PC, I am restricted by Framework from buying any parts.
The rationale behind restricting sales of PCs is understandable, but given how readily people get transferred and moved globally, it seems a bit impractical and unreasonable to enforce restriction of parts sales, which ultimately harms the repairable and upgradeable philosophy that founded Framework. The only alternative I have now is to buy an ordinary disposable PC as a replacement until I return, more e-wastes down the road. Exasperated …
Spent most the day installing Windows to USB - only managed to do this with